Comments 2
Интересный пример. Получается, мы превращаем тест в спецификацию, которой должны следовать сразу все наследники HelloSayer! По-моему, это довольно важный момент, на который стоит обратить больше внимания :)
Критики TDD нередко указывают на «игрушечность» примеров, используемых в TDD-статьях, но данный пример может быть далеко не игрушечным. В кровавой энтерпрайзоте можно встретить порой десятки наследников одного и того же интерфейса/класса. И возможность протестировать их на соответствие спецификации с помощью одного тестового сьюта выглядит весьма и весьма вкусно, имхо.
Критики TDD нередко указывают на «игрушечность» примеров, используемых в TDD-статьях, но данный пример может быть далеко не игрушечным. В кровавой энтерпрайзоте можно встретить порой десятки наследников одного и того же интерфейса/класса. И возможность протестировать их на соответствие спецификации с помощью одного тестового сьюта выглядит весьма и весьма вкусно, имхо.
Да именно так! Вы очень хорошо сформулировали. :))
В связи с этим, думаю, следует разделить тестирования создания объектов, так как это может быть специфично для каждого класса и, собственно, тестирование методов интерфейса, которое, на самом деле, должно быть единым для всех классов, реализующих этот интерфейс.
В связи с этим, думаю, следует разделить тестирования создания объектов, так как это может быть специфично для каждого класса и, собственно, тестирование методов интерфейса, которое, на самом деле, должно быть единым для всех классов, реализующих этот интерфейс.
Sign up to leave a comment.
Использование junit-quickcheck на простом примере в практике TDD