В TDD тесты должны быть записаны человеком, который реализовал опцию под тестом? [закрытый]
8 ответов
В TDD разработчик сначала пишет модульные тесты, которые терпят неудачу, а затем исправляет производственный код, чтобы тест прошел. Идея состоит в том, что изменения выполняются очень маленькими шагами - поэтому вы пишете тест, который вызывает метод, который не существует, затем вы исправляете тест, добавляя пустой метод, затем вы добавляете в тест какое-то утверждение о методе так что он снова терпит неудачу, затем вы реализуете первую часть метода и т. д. Поскольку эти шаги настолько малы, нецелесообразно поручить отдельному человеку писать тесты. С другой стороны, я бы порекомендовал спаривание, чтобы вы получили дополнительное внимание, убедившись, что код имеет смысл.
Я думаю, что можно было бы нанять другого человека / команду / или даже клиента (когда вы используете такие инструменты, как Fitness) для написания приемочных тестов, которые тестируют всю функциональность на более высоком уровне.
Одним из преимуществ TDD является быстрый цикл обратной связи. Если другой разработчик напишет тесты, это слишком сильно замедлит процесс. Один и тот же разработчик должен писать и то, и другое.
Я здесь немного запутался.
Вы говорите, что хотите использовать TDD, и, кажется, правильно понимаете, что программист пишет тест, затем тот же самый программист пишет реализацию и делает это в следующие несколько секунд / минут после написания теста. Это часть определения TDD. (кстати, «тот же программист» также означает «другой программист в паре», когда практикуется парное программирование).
Если вы хотите сделать что-то другое, сделайте это и напишите о своем опыте в блоге или в статье.
Чего вам не следует делать, так это говорить, что то, что вы делаете иначе, - это TDD.
Причина, по которой «один и тот же программист» написал реализацию и написал ее очень скоро после теста, заключается в целях быстрой обратной связи, чтобы узнать, как писать хорошие тесты, как хорошо разрабатывать программное обеспечение. и как писать хорошие реализации.
См. Три правила Tdd .
Модульный тест должен быть написан до кодирования и проверять, что модуль соответствует требованиям, поэтому он должен Пусть разработчик, реализующий код, также напишет модульный тест.
Согласно ответу Джастина, разработчик не только может написать тест, но и является стандартом де-факто. Теоретически допустимо написать тест и другим программистам. Я играл с идеей "тестового" программиста, поддерживающего "функционального" разработчика, но я не встречал примеров.
Если я пишу тест для объекта, помимо ожидаемых входов и выходов, я должен знать интерфейс, который он предоставляет. Другими словами, тестируемые классы и методы должны быть определены до начала разработки. За двенадцать лет я только один раз работал в магазине, который достиг такой детализации дизайна до того, как началась разработка. Я не уверен, каким был ваш опыт, но мне это не кажется очень гибким.
Я думаю, вам нужно отделить автоматизированное модульное тестирование от разработки, управляемой тестированием. (ИМХО, не только вам следует делать здесь важное различие ).
AUT настоятельно рекомендует, TDD требует, чтобы сначала был написан тест.
TDD, кроме того, делает тест важной частью процесса написания кода. TDD - это не столько метод обеспечения качества, сколько способ думать о коде, поэтому разделение ответственности противоречило бы философии TDD. Они также были бы непрактичными - цикл нового тестирования / нового кода очень мал, обычно это вопрос минут. В моем понимании, Test Driven Design было бы лучшим описанием.
AUT может быть приспособлен к существующей кодовой базе (хотя часто плохо, в зависимости от размера и структуры кодовой базы). Разделение обязанностей может иметь здесь некоторые преимущества. Тем не менее, AUT оказывает некоторое давление на дизайн - поэтому разделение будет на уровне , который набирает код .
Отличие: Я открыто признаю, что мне не нравится идея TDD. Это может хорошо работать для определенного типа кодировщика, для определенных приложений, на определенных рынках, но все примеры, демонстрации и пошаговые инструкции, которые я видел до сих пор, заставляют меня содрогаться. OTOH, я считаю AUT ценным инструментом для обеспечения качества. Один ценный инструмент.
Это можно сделать и так, и так: вы можете написать модульный тест самостоятельно или использовать подход "пинг-понг", когда вы по очереди с другим разработчиком пишете модульные тесты и пишете реализацию, если вы работаете в паре. Правильное решение - это то, которое подходит вам и вашей команде. Я предпочитаю писать тесты сам, но я знаю других людей, которым повезло и с подходом "пинг-понг".
Юнит-тесты и приемочные тесты - это две разные вещи, и обе они могут (и должны) выполняться в TDD. Юнит-тесты пишутся с точки зрения разработчика, чтобы убедиться, что код делает то, что он ожидает. Приемочные тесты пишутся с точки зрения заказчика, чтобы убедиться, что код удовлетворяет соответствующую потребность. Приемочные тесты могут быть написаны кем-то другим (обычно потому, что это требует несколько иного мышления и знания области, а также потому, что они могут выполняться параллельно), но модульные тесты должны быть написаны разработчиком.
TDD также говорит, что вы не должны писать никакого кода, кроме как в ответ на неудачный тест, поэтому необходимость ждать, пока кто-то другой напишет Unit-тесты, кажется довольно неэффективной.