Как использовать TDD, когда фиксация включает изменение метода под подписью теста?
Поведение вашей программы не определено.
Арифметика указателей действительна только в массивах. И r, g, b не образуют массив.
Лучше всего перекодировать float& operator[](size_t) с помощью блока switch, содержащего 3 метки.
7 ответов
Нет абсолютно ничего неправильно со взрывом Ваших тестов, когда Вы обнаруживаете, что намеченное поведение единицы изменяется.
//Up front
[Test]
public void should_remove_correct_token_from_string()
{
var text = "do.it.correctly..";
var expected = "doitcorrectly";
Assert.AreEqual(StaticClass.RemoveTokenFromString(text, "."), expected);
}
//After finding that it doesn't do the right thing
//Delete the old test and *design* a new function that
//Does what you want through a new test
//Remember TDD is about design, not testing!
[Test]
public void should_remove_correct_token_from_string()
{
var text = "do.it.correctly..";
var expected = "doitcorrectly";
Assert.AreEqual(
StaticClass.RemoveTokenFromString(
text,
".",
System.Text.Encoding.UTF8), expected);
}
//This will force you to add a new parameter to your function
//Obviously now, there are edge cases to deal with your new parameter etc.
//So more test are required to further design your new function
Сохраните это простым.
Если Ваш модульный тест является неправильным, или устаревшим, необходимо переписать его. Если Ваши спецификации изменяются, или определенные спецификации больше не релевантны, Ваши модульные тесты должны отразить это.
Красный, зеленый, осуществите рефакторинг, также относится к Вашим модульным тестам, не только коду, который Вы тестируете.
Вы попали в самую опасную ловушку в TDD: вы думаете, TDD о тестировании, но это не так. Однако попасть в эту ловушку легко, поскольку вся терминология в TDD относится к тестированию. Вот почему BDD был изобретен: это, по сути, TDD, но без запутанной терминологии.
В TDD тесты - это не тесты, а примеры. И утверждения на самом деле не утверждения, а ожидания. И вы не имеете дело с юнитами, вы имеете дело с поведением. BDD просто называет их так. (Примечание: BDD эволюционировал с момента его первого изобретения, и теперь он включает в себя вещи, которые не являются частью TDD, но первоначальное намерение было просто «многие люди делают TDD неправильно, поэтому используйте разные слова, чтобы помочь им сделать это правильно». )
Во всяком случае, если вы думаете о тесте не как о тесте, но поведенческий пример того, как метод должен работать, должно стать очевидным, что по мере того, как вы лучше понимаете ожидаемое поведение, удаление или изменение теста допускается не только TDD, но и является единственным правильным выбором ! Всегда имейте это в виду!
Существует рефакторинг под названием, Добавляет Параметр, который мог помочь здесь.
Если Ваш язык поддерживает перегрузку метода, Вы могли бы создать новую функцию с новым параметром сначала, копируя тело существующей функции и решив Вашу проблему.
Затем, когда проблема решена, можно изменить все тесты, один за другим, для вызова нового метода. В последний раз можно удалить старый метод.
С языком, который не поддерживает перегрузку метода, создайте новую функцию с другим именем, скопируйте тело на существующей функции в той новой функции, имейте существующую функцию, вызывающую новую функцию, возможно с фиктивным значением для нового параметра. Затем у Вас могла быть вся своя тестовая передача. Выполните свой старый тестовый вызов новая функция, один за другим. Когда старый метод больше не используется, он может быть удален, и новая функция переименована.
Это немного обширно процессом, но я думаю, что это - TDD способ следовать за red-green-refactor.
Значение по умолчанию для параметра могло также помочь, если там доступны.
Красный, зеленый, осуществить рефакторинг.
Независимо от того, что Вы делаете, Вы сначала хотите добраться до состояния, где у Вас есть компиляция, но сбой тестового сценария, который воспроизводит ошибку. Затем можно продолжить двигаться при добавлении просто параметра к тесту и реализации, но ничего не сделать с ним так, Вы все еще имеете Красный.
Если метод не делает задания правильно затем, это должно быть зафиксировано и если фиксация требует изменения в подписи, затем отмечающей неправильно в этом. Согласно TDD Вы пишете тестовый сценарий сначала, который, конечно, перестанет работать, и затем Вы пишете метод для удовлетворения теста. Согласно этому подходу, если вызов метода в тесте требует, чтобы параметр для него функционировал затем, необходимо сделать это.
Я сказал бы, не разъедают о 'праве'/'correct' путь... независимо от того, что помогает Вам получить Вас ближе к более быстрому решению.
Если Вы находите, что необходимо взять в дополнительном параметре,
- обновите вызов в тестовом сценарии
- добавьте новый параметр к фактическому методу
- проверьте, что Ваши сборки кода и тест перестали работать снова.
- возобновите создание его зеленый.
Только в случаях, где добавление нового параметра привело бы к огромному количеству ошибок компиляции, будет я рекомендовать - взятие его в маленьких шагах... Вы не хотите обновлять целую исходную основу перед обнаружением, что Вам действительно не был нужен третий параметрический усилитель, или Вам нужен четвертый.. время потеряно. Поэтому получите новую версию метода, 'работающего' прежде, чем обновить все ссылки. (Как philippe говорит здесь),
- запишите новую перегрузку с добавленным параметром
- Переместите код старого метода в новую перегрузку
- Сделайте старое реле перегрузки или делегата в новой перегрузке с некоторым значением по умолчанию для нового параметрического усилителя
- Теперь можно возвратиться к задаче под рукой и заставить новый тест идти зеленый.
- Если Вы больше не нуждаетесь в старой перегрузке, удаляете ее и фиксируете получающиеся ошибки компиляции.