В последнее время, пытаясь внедрить больше практик TDD для проекта, я столкнулся с ситуацией, касающейся тестов, которые охватывают будущие требования, и мне интересно, как другие решают эту проблему.
Скажем, к примеру, я занимаюсь разработкой приложения SuperUberReporting, текущая версия 1.4. Поскольку я разрабатываю функции, которые должны быть включены в SuperUberReporting 1.5, я пишу тест для новой функции экспорта файлов, которая позволит экспортировать результаты отчетов в файл CSV. Во время написания этого теста мне пришло в голову, что функция поддержки экспорта в некоторые другие форматы намечена для более поздних версий 1.6, 1.7 и 1.9, которые задокументированы в программном обеспечении для отслеживания проблем. Теперь вопрос, с которым я сталкиваюсь, заключается в том, должен ли я писать тесты для этих других форматов или мне следует подождать, пока я действительно не реализую эти функции? Этот вопрос затрагивает нечто более фундаментальное в отношении TDD, которое я хотел бы задать более широко.
Могут ли / должны ли тесты быть написаны заранее, как только требования станут известны, или степень стабильности требований как-то определит, следует ли писать тест или нет?
В целом, как далеко должны быть написаны тесты? Можно ли написать тест, который потерпит неудачу в течение двух лет, пока не планируется реализовать эту функцию? Если это так, то как можно организовать свои тесты, чтобы разделить тесты, которые необходимо пройти, и тесты, которые не пока не требуются для прохождения? В настоящее время я использую NUnit для проекта .NET, поэтому я не возражаю против специфики, поскольку они могут лучше продемонстрировать, как добиться такой организации.