Це гарна ідея робити TDD на компонентах низького рівня?

Я розглядаю можливість написання драйвера низького рівня або компонентів / ядер ОС.

Люди на osdev.org, здається, думають, що важливі шматочки не мають сенсу перевірити таким чином, але я прочитав деякі дискусії, де люди думали інакше. Я оглянувся, але не зміг знайти жодного прикладу реального життя TDD на компонентах низького рівня.

Це щось, що насправді роблять люди, чи просто те, про що люди говорять теоретично, тому що немає хорошого способу зробити це на практиці?

Якщо ви взаємодієте з обладнанням або контролюєте його, то без нього важко перевірити. Ви можете спробувати емуляцію обладнання, але це часто складніше, ніж писати драйвер в першу чергу, так що ви не знаєте, чи є помилка у вашому драйвері чи вашому емуляторі.

Я особисто схильний вважати, що можна отримати багато переваг TDD (без фактичного дотримання TDD) шляхом:

• Написання як абонента, так і коду абонента приблизно в один і той же час (безумовно, не більше 24 годин).
  • І використовуйте це, щоб впливати на дизайн інтерфейсу (об'єкти, виклики методів та параметри).
• Для компонента, що потребує складного алгоритму / коду, спочатку розглядайте можливість реалізації в більш простому, але правильному алгоритмі, навіть якщо він менш ефективний (або дурний, або працює лише у вужчій ситуації).
  • Дуже простим методом тестування було б запуск обох алгоритмів та порівняння їх результатів.
• Після виявлення помилки (будь-якими способами) в одній частині коду, ця частина коду заслуговує на тест набагато агресивніше. Це означає робити більш складні тести, ніж вимагає TDD. (виходячи з міркувань про те, що помилки трапляються в кластерах )

Здається, TDD вимагає від вас досить чіткого розуміння того, яку функцію ви плануєте реалізувати або які вимоги ви плануєте задовольнити, застосовуючи код. У деяких ситуаціях просто недостатньо розуміння проблеми. Це вимагало б рішення Спайка . У рамках цього рішення Spike можна застосувати TDD, оскільки проблема була звужена до керованого рівня. Після закінчення декількох шипів, кожен з яких охоплює деякі аспекти оригінальної проблеми, можна починати працювати над повним рішенням, і застосування TDD в цій точці може бути здійснене через покращене розуміння.

Відредаговано:

Прочитавши сторінку уважніше,

Хоча має бути можливість протестувати більшість функцій ядра в "testbed" тестовому драйвері, справді "соковиті" речі, такі як обробка переривань, диспетчеризація процесів або управління пам'яттю, ймовірно, не перевіряють одиниці. --- з http://wiki.osdev.org/Unit_Testing

Вони чітко говорять про те, що більшість деталей є тестовими, а деякі частини вимагають іншого виду тестування: тест на стрес .

Я не. У вбудованому коді майстра я просто записую код і витрачаю свій час на міркування про те, що він робить (а що ні). Я не впевнений, що це могло бути зроблено в моєму випадку, я тривожно наближаюся до фізичної межі пам'яті без введення коду тестування.

Я думаю, що для систем, які є досить великими (тобто мають МБ пам'яті, а не КБ), це можна зробити для деяких компонентів, якщо у вас вистачить часу та зусиль. Тестування коду читання PIN-кодом знущанням над штифтами вгору ... не дуже важливо. Якщо ви досить відокремили свою логіку, ви можете перевірити її в іншому місці.

FWIW, я не купую TDD в загальному випадку - він прекрасно працює для системних стеків, які є достатньо великими з достатньою кількістю ресурсів з достатньою детермінованою поведінкою, поза цим це не здається розумною практикою.