В TDD каждая строка кода должна быть подтверждена неудачным тестом, написанным перед кодом.
Это означает, что вы не можете разработать любой код без тестового случая. Если у вас есть строка кода (условие, ветвь, присваивание, выражение, константа и т. Д.), Которую можно изменить или удалить без провала какого-либо теста, это означает, что эта строка кода бесполезна, и должно быть * 1008. * удален (или у вас отсутствует тест для подтверждения его существования).
Это немного экстремально, но так работает TDD. При этом, если у вас есть кусок кода, и вы задаетесь вопросом, должен ли он быть протестирован или нет, вы неправильно выполняете TDD. Но если у вас есть подпрограмма форматирования строки или инкремент переменной или любой другой небольшой фрагмент кода, должен быть тестовым примером, поддерживающим ее.
ОБНОВЛЕНИЕ (вариант использования, предложенный Ред. ):
Как, например, добавление объекта в список и создание теста, чтобы увидеть, действительно ли он внутри или есть дубликат, когда список не должен разрешать их.
Вот контрпример, вы будете удивлены, насколько сложно определить ошибки копирования и вставки и насколько они распространены:
private Set<String> inclusions = new HashSet<String>();
private Set<String> exclusions = new HashSet<String>();
public void include(String item) {
inclusions.add(item);
}
public void exclude(String item) {
inclusions.add(item);
}
С другой стороны, тестирование include() и exclude() методов само по себе является излишним, потому что они сами по себе не представляют никаких вариантов использования. Тем не менее, они, вероятно, являются частью бизнес-прецедента, вместо этого вам следует протестировать.
Очевидно, что вы не должны проверять, действительно ли x в x = 7 7 после назначения. Также тестирование сгенерированных геттеров / сеттеров является излишним. Но это самый простой код, который часто ломается. Слишком часто из-за ошибок копирования и вставки или опечаток (особенно в динамических языках).
Смотри также: