Состязательное/наивное сопряжение с TDD:Насколько это эффективно?

Question

Мой друг объяснял, как они объединяются в пинг-понг с TDD на своем рабочем месте, и сказал, что они используют «состязательный» подход.То есть, когда человек, пишущий тест, передает клавиатуру разработчику, тот пытается сделать самое простое (а иногда и неправильное) действие, чтобы тест прошел.

Например, если они тестируют метод GetName() и тест проверяет наличие «Салли», реализация метода GetName будет просто такой:

public string GetName(){
    return "Sally";
}

Что, конечно, выдержит испытание (наивно).

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

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

Используете ли вы этот подход, и если да, то оправдали ли вы его?

Answer 1

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

return "Sally";

Это разочарование приведет к неудаче команды.Я был среди разочарованных и не видел, чтобы это окупилось.Я думаю, что лучший подход — это устное общение с предложениями о том, как лучше реализовать тест.

Answer 2

Это может быть очень эффективно.

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

Вы создаете код по частям, часто нажимая на клавиатуру.

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

Answer 3

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

Answer 4

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

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

Answer 5

(Во-первых, Adversarial TDD должен доставлять удовольствие.Это должна быть возможность для обучения.Это не должно быть возможностью для ритуалов человеческого доминирования.Если нет места юмору, покиньте команду.Извини.Жизнь слишком коротка, чтобы тратить ее в негативном окружении.)

Проблема здесь в неудачно названных тестах.Если бы тест выглядел так:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

Тогда я готов поспорить, что его назвали "testGetNameReturnsNameField".Это дурное имя, но не сразу это становится очевидным.Правильное название этого теста: «testGetNameReturnsSally".Вот что он делает.Любое другое имя вызывает у вас ложное чувство безопасности.Итак, тест неудачно назван.Проблема не в коде.Проблема даже не в тесте.Проблема в названии теста.

Если бы вместо этого тестер назвал тест "testGetNameReturnsSally", тогда сразу было бы очевидно, что это, вероятно, не тестирование того, что мы хотим.

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

Так много ошибок в производстве возникает не потому, что код сделал меньше, чем ожидалось, а потому, что он сделал больше.Да, были модульные тесты для всех ожидаемых случаев, но не было тестов для всех особых крайних случаев, которые выполнял код, потому что программист подумал: «Лучше я тоже это сделаю, это нам, вероятно, понадобится», а затем забыл об этом. это.Вот почему TDD работает лучше, чем test-after.Вот почему мы выбрасываем код после всплеска.Код может делать все, что вы хотите, но, скорее всего, он делает то, что вы считали нужным, а потом забыли.

Заставьте автора теста тестировать то, что он действительно хочет.Пишите код только для прохождения тестов и не более того.

RandomStringUtils — ваш друг.