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

10

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

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

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

Билл
источник
Если бы только MS предоставила разработчикам ядра соответствующие «макеты ядра» (или что бы то ни было), рассматриваемая практика не была бы такой «творческой», я думаю.
mlvljr
Привет @Bill - Я немного перефразировал твой вопрос и проголосовал за его повторное открытие. Если я изменил это слишком сильно по сравнению с вашим первоначальным намерением, пожалуйста, не стесняйтесь редактировать дальше или отменить вопрос :)
Рэйчел
Говорит то же самое с моей точки зрения - не беспокойтесь
Билл

Ответы:

3

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

TMN
источник
1
А почему бы тогда не проверить эмулятор? ;)
mlvljr
@mlvljr: потому что эмуляторы не настоящие. ничто не заменит реальное оборудование.
Пол Натан
@mlvljr Вам также нужно протестировать эмулятор на реальном оборудовании, используя наборы тестов, созданные для тестирования оригинальных тестов на ... подождите, где я снова?
Обратите внимание на себя - придумайте имя
Значит, vmware и другие не могут быть протестированы?
mlvljr
1
@mlvljr: Это верная точка зрения, но я думаю, что она выходит за рамки «TDD». Не многие разработчики имеют доступ к инструментальному эмулятору системного уровня, который может быть использован для сценариев. Мне повезло иметь четырехканальный прицел!
TMN
3

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

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

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

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

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

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

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

rwong
источник
это также подразумевает, что важными частями являются те части, которые требуют различных испытаний imho.
Билл
какой потрясающий ответ! в некоторых многих уровнях ура!
manuelBetancurt
1

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

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

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

Пол Натан
источник