Должны ли мы удалить тесты, которые слишком просты, чтобы сломать во время TDD

Question

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

Answer 1

номер

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

Answer 2

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

Но, конечно, реальность тестов немного сложнее, чем просто ответ да / нет на этот вопрос. Как отмечено в другом ответе, если вы уже написали тесты, не удаляйте их. Но вам также не следует использовать их в контексте покрытия кода в качестве аргумента уверенности.

Answer 3

Вы говорите, что это слишком просто, чтобы потерпеть неудачу:

for (i = 0; i < observers.length; ++i) {
    // Notify observer observers[i]
}

Заманчиво думать об этом, но учтите эту распространенную ошибку:

for (i = 0; i <= observers.length; ++i) {
    // Notify observer observers[i]
}

Или вот этот:

for (i = 0; i < observers.length; ++j) {
    // Notify observer observers[i]
}

Или, возможно, наблюдатели не добавляются правильно. Или ... или ... или ...

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

Answer 4

Чем больше у вас будет тестов, тем меньше будет боли в будущем. Не берите в голову их простоту.

Answer 5

номер

Вы делаете все правильно: пишете тесты, которые сначала не пройдены, а затем исправляете их. Оставьте эти тесты в покое, напишите более сложные в будущем, если вы считаете, что они вам понадобятся (например, для воспроизведения ошибок).

Answer 6

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

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

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

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