Мы запускаем проект, в котором мы хотим решить с помощью тестовой разработки. Я подумал о некоторых вопросах, которые возникли при запуске проекта. Один вопрос: кто должен написать unit-тест для какой-либо функции? Должен ли блок-тест быть написан программистом-исполнителем? Или должен ли unit test быть написан другим программистом, который определяет, что должен делать метод, и программист, реализующий функцию, реализует этот метод до тех пор, пока тесты не пройдут?
Если я правильно понимаю концепцию TDD, программист-программист должен сам написать тест, потому что TDD - это процедура с мини-итерациями. Так что было бы слишком сложно иметь тесты, написанные другим программистом?
Что бы вы сказали? Должны ли тесты в TDD записываться самим программистом или если другой программист пишет тесты, которые описывают, что может сделать метод?
В TDD, должны ли тесты быть написаны лицом, выполнившим тестируемую функцию?
Ответ 1
В TDD разработчик сначала записывает единичные тесты, которые терпят неудачу, а затем фиксирует производственный код для прохождения теста. Идея состоит в том, что изменения сделаны на очень маленьких шагах - поэтому вы пишете тест, который вызывает метод, который не существует, затем вы устанавливаете тест, добавляя пустой метод, затем добавляете некоторое утверждение к тесту о методе поэтому он снова не работает, тогда вы реализуете первый разрез метода и т.д. Поскольку эти шаги настолько малы, нецелесообразно, чтобы отдельный человек записывал тесты. С другой стороны, я бы рекомендовал спаривание, чтобы вы получили дополнительные глазные яблоки, убедившись, что код имеет смысл.
Я думаю, что было бы возможно, чтобы другой человек/команда/или даже клиент (когда вы используете такие инструменты, как Fitness), чтобы писать приемочные тесты, которые проверяют всю функциональность на более высоком уровне.
Ответ 2
Одним из преимуществ TDD является цикл быстрой обратной связи. Еще один разработчик напишет, что тесты замедлят процесс слишком сильно. Тот же разработчик должен написать оба.
Ответ 3
Единичные тесты и тесты приемочных испытаний - это две разные вещи, которые могут (и должны) выполняться в TDD. Модульные тесты записываются с точки зрения разработчика, чтобы убедиться, что код выполняет то, что она ожидает. Приемочные тесты записываются с точки зрения клиента, чтобы убедиться, что код удовлетворяет соответствующую потребность. Это может иметь большое значение для того, чтобы тесты приемочного тестирования были написаны кем-то другим (обычно потому, что для этого требуется немного другое мышление и знание домена, а также потому, что они могут выполняться параллельно), но Unit Tests должен быть написан разработчиком.
TDD также говорит, что вы не должны писать какой-либо код, кроме как в ответ на неудачный тест, поэтому, чтобы ждать, пока кто-то еще напишет, тесты Unit кажутся довольно неэффективными.
Ответ 4
Это можно сделать в обоих направлениях, вы можете написать unit test самостоятельно или пойти на подход пинг-понга, где поочередно поменялись с другими модулями тестирования разработчика и написанием реализации, если вы спариваетесь. Правильное решение - это то, что работает для вас и вашей команды. Я предпочитаю сам писать тест, но я знаю других, которым также повезло с подходом к пинг-пону.
Ответ 5
Unit Test должен быть записан до кодирования и проверки того, что Единица соответствует требованиям, поэтому разработчику, выполняющему этот код, должно быть хорошо, чтобы также написать Unit Test.
Ответ 6
Я думаю, вам нужно отделить автоматическое тестирование единицы из Test Driven Development. (ИМХО это не только вы, кто должен сделать здесь важное различие).
AUT настоятельно рекомендует, TDD требует, чтобы тест был написан первым.
TDD также делает тест важной частью процесса написания кода. TDD - это не столько метод обеспечения качества, сколько способ думать о коде, поэтому отдельные обязанности будут противоречить философии TDD. Они также были бы непрактичными - новые тесты/новые коды кода очень малы, обычно это вопрос минут. По моему мнению, Test Driven Дизайн будет лучшим описанием.
AUT может быть установлен на существующую базу кода (хотя часто это плохо, в зависимости от размера и структуры базы кода). Отдельные обязанности могут иметь некоторые преимущества. Тем не менее, AUT оказывает некоторое давление на дизайн, поэтому разделение будет на том, кто вводит уровень кода.
Различие: Я свободно признаю, что мне не нравится идея TDD. Это может хорошо работать для определенного типа кодеров для определенных приложений на определенных рынках, но все примеры, демонстрации и пошаговые руководства, которые я видел до сих пор, заставляют меня дрожать. OTOH, я считаю AUT важным инструментом обеспечения качества. Один ценный инструмент.
Ответ 7
Я немного запутался здесь.
Вы говорите, что хотите использовать TDD, и вы, кажется, правильно понимаете, что программист пишет тест, затем тот же самый программист пишет реализацию и делает это в течение следующих нескольких секунд/минут после написания теста. Это часть определения TDD. (btw "тот же самый программист" также означает "другой программист в паре" при осуществлении парного программирования).
Если вы хотите сделать что-то другое, тогда зайдите на него и напишите свой опыт в блоге или статье.
То, что вы не должны делать, это сказать, что то, что вы делаете другим, - это TDD.
Причина того, что "тот же самый программист" пишет реализацию, и записывая ее очень скоро после теста для быстрой обратной связи, чтобы узнать, как писать хорошие тесты, как правильно проектировать программное обеспечение и как писать хорошие реализации.
См. Три правила Tdd.
Ответ 8
Ответ Пер Джастина не только отлично подходит для того, чтобы разработчик мог написать тест, это стандарт де-факто. Теоретически это также приемлемо для другого программиста, чтобы написать тест. Я поиграл с идеей "тест-программиста", поддерживающего "особенного" разработчика, но я не встречал примеров.
Если я пишу тест для объекта, в дополнение к входу и выводам, которые я ожидаю, я должен знать интерфейс, который он предоставляет. Другими словами, классы и методы, подлежащие тестированию, должны быть определены до начала разработки. За двенадцать лет я только однажды работал в магазине, который достиг этой гранулярности дизайна до начала разработки. Я не уверен, каковы были ваши переживания, но мне это не кажется очень гибким.