Это хорошая идея сделать TDD на компонентах низкого уровня?

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

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

Это то, что люди на самом деле делают, или просто то, о чем люди говорят в теории, потому что на практике нет хорошего способа сделать это?

Если вы взаимодействуете с аппаратным обеспечением или управляете им, то без него сложно протестировать. Вы можете попробовать эмулировать аппаратное обеспечение, но это зачастую сложнее, чем сначала написать драйвер, поэтому вы не узнаете, есть ли ошибка в вашем драйвере или эмуляторе.

Лично я склонен полагать, что можно получить много преимуществ TDD (фактически не придерживаясь TDD), путем:

• Написание как вызывающего, так и вызываемого кода примерно в одно и то же время (определенно с интервалом не более 24 часов).
  • И используйте это, чтобы влиять на дизайн интерфейса (объекты, вызовы методов и параметры).
• Для компонента, требующего сложного алгоритма / кода, настоятельно рекомендуется сначала реализовать более простой, но правильный алгоритм, даже если он менее эффективен (или глуп, или работает только в более узкой ситуации).
  • Очень простой метод тестирования - запуск обоих алгоритмов и сравнение их результатов.
• Как только ошибка обнаружена (любым способом) в одной части кода, эта часть кода заслуживает более агрессивного тестирования. Это означает проведение более сложных тестов, чем требовало бы TDD. (на основании рассуждений о том, что ошибки возникают в кластерах )

Похоже, что TDD требует от вас четкого понимания того, какую функцию вы планируете реализовать, или какие требования вы планируете удовлетворить путем реализации кода. В некоторых ситуациях просто слишком мало понимания проблемы. Это вызвало бы решение Spike . В рамках этого решения Spike может применяться TDD, поскольку проблема была сужена до управляемого уровня. После завершения нескольких пиков, каждый из которых охватывает некоторые аспекты исходной проблемы, можно начинать работу над полным решением, и применение TDD на этом этапе может оказаться возможным из-за улучшенного понимания.

Отредактировано:

После более внимательного прочтения страницы,

В то время как должна быть возможность протестировать большинство функций ядра в «тестовом» тестовом драйвере, по-настоящему «сочные» вещи, такие как обработка прерываний, диспетчеризация процессов или управление памятью, вероятно, не подлежат модульному тестированию. --- с http://wiki.osdev.org/Unit_Testing

Они четко говорят, что большинство деталей являются тестируемыми, а некоторые детали требуют другого вида тестирования: стресс-тестирование .

Я не. Во встроенном коде моего Мастера я просто пишу код и провожу время, размышляя о том, что он делает (а чего нет). Я не уверен, что это могло быть сделано в моем случае, так или иначе, я приближаюсь к физическому пределу памяти, не вводя тестовый код.

Я думаю, что для систем, которые достаточно велики (т.е. имеют МБ памяти, а не КБ), это можно сделать для некоторых компонентов, если у вас есть достаточно времени и усилий. Тестирование кода чтения пин-кода с помощью насмешки контактов ... э-э ... не очень важно. Если вы достаточно разобрали свою логику, вы можете проверить логику в другом месте.

FWIW, я не покупаю TDD в общем случае - он прекрасно работает для стеков системы, которые достаточно велики, с достаточным количеством ресурсов и достаточно детерминированным поведением, за исключением того, что это не кажется разумной практикой.