TDD как стратегия устранения дефектов

Question

Может ли TDD быть успешным в качестве стратегии устранения дефектов без включения руководства по построению и оценке контрольного примера?

Answer 1

ИМО, мой ответ будет нет. Для того чтобы TDD был эффективным, должны быть указания относительно того, что такое тест и что значит «что-то проверять». Без руководства могут быть некоторые разработчики, которые в конечном итоге сталкиваются с множеством дефектов, поскольку их первоначальные тесты охватывают очень небольшой набор входных данных, например только действительные, которые могут привести к тому, что идея использования TDD станет бесполезной.

Answer 2

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

Если документация плохая (что во время разработки "часто"), тесты показывают, как вы ожидаете, что ваш код будет вызываться. Таким образом, даже в тех случаях, когда код действительно очень хрупок, TDD все еще может уменьшить количество дефектов, возникающих в конечном продукте, - благодаря тому, что ваши коллеги могут увидеть хорошо написанные тесты, прежде чем они смогут использовать ваш код, вы они знают, как вы собираетесь использовать ваш код, прежде чем они его вызовут. Таким образом, они с меньшей вероятностью будут вызывать ваш код в неожиданной последовательности / не настроив то, что вы ожидали (но забыли написать проверку) в качестве предварительного условия. Таким образом, они с меньшей вероятностью вызовут состояние сбоя, и вы с меньшей вероятностью увидите, что они или (человеческая) группа тестирования выявляют дефект, потому что что-то сломалось.

Конечно, видите ли вы, что "там есть скрытая ошибка, она просто еще не вызывается", поскольку сама проблема - еще один хороший вопрос.

Answer 3

Возможно, вы захотите забрать копию xUnit Test Patterns Джерарда Месароса . В частности, глава 5 может быть наиболее применима к вашему вопросу, где она охватывает принципы автоматизации тестирования. Некоторые из тех принципов, которые, я думаю, применимы к вашему сценарию, когда необходимо какое-то руководство, общий интерес или что-то вроде того, что делает это или боится гнева:

• Принцип: сообщить о намерениях
  • Тесты должны быть простыми в обслуживании, и должно быть понятно, что делает тест.
• Принцип: независимость тестов
  • Маленькие тесты, которые охватывают один маленький кусочек. Испытания не должны мешать друг другу.
• Принцип: минимизировать наложение теста
  • Необходимо разрабатывать тесты, которые охватывают конкретный фрагмент, и не создавать тесты, которые повторяют одни и те же пути.
• Принцип: проверить одно условие на тест
  • Этот мне показался достаточно простым, но в моем опыте это был один из самых сложных для понимания людей. Я могу написать тесты, в которых есть несколько утверждений, но я стараюсь держать их вместе в определенной области. Когда дело доходит до поиска сбоев и других проблем с тестами, НАМНОГО проще играть с одним тестом, который тестирует определенный путь, а не с несколькими различными путями, объединенными в один метод тестирования.

Далее, в отношении моего опыта, если мы хотим поговорить о корпоративном разработчике, я видел некоторых людей, которые заинтересованы и проявляют инициативу, чтобы узнать что-то новое, но чаще всего у вас есть люди, которым нравится идти с поток, и хотел бы, чтобы вещи были изложены для них. Без какого-либо направления, будь то мандат от старшего инженера или какие-то дискуссии в совместной команде (некоторые идеи, такие как встречи во время обеда раз в неделю, см. В разделе «Практика гибкого разработчика»), я думаю, что ваш шанс успех будет ограничен.

Answer 4

Вот исследование (предупреждение: ссылка на файл PDF) , проведенное Microsoft в некоторых из их внутренних групп.

Цитата из него:

Результаты тематических исследований показывают, что плотность дефектов перед выпуском четырех продуктов снизилась на 40-90% по сравнению с аналогичными проектами, в которых не использовалась практика TDD. Субъективно, после принятия TDD

команды испытали увеличение начального времени разработки на 15–35%

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

Исходя из моего собственного опыта, определенно наблюдается уменьшение количества дефектов, но эти цифры кажутся гораздо меньшими, чем даже 40% от исследования Microsoft; Это (опять же, основано исключительно на том, что я видел), главным образом потому, что большинство корпоративных разработчиков практически не имеют опыта работы с модульным тестированием (не говоря уже о TDD) и будут неизменно делать плохую работу во время обучения. На самом деле, для того, чтобы хорошо понять, как правильно работать с TDD, требуется, по крайней мере, солидный опыт работы, и я никогда не работал (или даже не видел ) в команде, которая фактически имела бы полный набор разработчиков с таким опытом.

Answer 5

если у вас нет тестов для воспроизведения дефектов, откуда вы знаете, что произошло «уменьшение дефектов»?

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

Answer 6

Разработка, основанная на тестировании, может уменьшить количество дефектов в цикле QA просто потому, что тестирование позволяет разработчикам находить дефекты перед выпуском кода для команды QA.

Но без указания , как проверить, вы действительно не сможете получить какую-либо долгосрочную выгоду, так как случайное тестирование будет предотвращать дефекты только при слепой удаче. Хорошие тесты, основанные на хороших рекомендациях, могут иметь большое значение для уменьшения дефектов.