Сопутствующее / наивное соединение с TDD: насколько оно эффективно?

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

RandomStringUtils - ваш друг.

Answer 4

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

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

Answer 5

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

return "Sally";

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