Для TDD вы должны
- Создать тест, который не прошел
- Сделайте самое простое, что могло бы сработать, чтобы пройти тест
- Добавьте еще варианты теста и повторите
- Рефакторинг при появлении шаблона
При таком подходе вы предполагаете охватить все случаи (по крайней мере, мне это кажется), но мне интересно, слишком ли я строгий здесь и возможно ли «думать вперед» некоторые сценарии, а не просто открыть их.
Например, я обрабатываю файл, и если он не соответствует определенному формату, я должен выбросить InvalidFormatException
Итак, мой первый тест был:
@Test
void testFormat(){
// empty doesn't do anything nor throw anything
processor.validate("empty.txt");
try {
processor.validate("invalid.txt");
assert false: "Should have thrown InvalidFormatException";
} catch( InvalidFormatException ife ) {
assert "Invalid format".equals( ife.getMessage() );
}
}
Я запускаю его, и он терпит неудачу, потому что он не выдает исключение.
Итак, следующее, что приходит мне в голову: «Делай самое простое, что могло бы сработать» , поэтому я:
public void validate( String fileName ) throws InvalidFormatException {
if(fileName.equals("invalid.txt") {
throw new InvalidFormatException("Invalid format");
}
}
Doh !! ( хотя реальный код немного сложнее, я обнаружил, что сам делаю что-то подобное несколько раз )
Я знаю, что мне нужно в конечном итоге добавить другое имя файла и другой тест, который сделает этот подход нецелесообразным и заставит меня рефакторинг к чему-то, что имеет смысл (что, если я правильно понял, это смысл TDD, чтобы обнаружить шаблоны использования раскрывают) но:
Q: Я слишком буквально воспринимаю "Делай самое простое ..." материал?