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