Здравствуйте, A.J., Вы писали:

AJ>Здравствуйте, _vovin, Вы писали:

AJ>>>То есть получается — если уже начал писать программу без ТДД, то все, поезд
AJ>>>ушел?

_>>Не совсем.
_>>Действительно, как правило, программа, написанная без использования TDD, позже очень плохо поддается unit-тестированию. Стандартный подход заключается в том, чтобы постепенно преобразовывать куски кода к новому виду, когда возникает необходимость сделать там какие-либо изменения.
_>>Проверенный способ, который позволяет в старых проектах нормализовать ситуацию с баг-фиксингом и постепенно увеличить test-coverage.

AJ>Так вопрос в том — чем этот "новый" вид отличается от старого-то?? (при условии, что система хорошо спроектирована, декомпозиция задачи выполнена грамотно, и т.п.)

Новый вид создан с точки зрения использования. Старый в большинстве случаев с точки зрения реализации. Стоит попробовать, чтобы почувствовать разницу.

AJ>>>Как, скажем, будет выглядеть тест (или набор тестов), проверяющий выполнение такого требования: любой XHTML-документ, соответствующий DTD, должен быть корректно преобразован в собственное программное представление (иерархию элементов)?

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

AJ>Так вот с этого и надо было начинать Получается, тестировать можно только на уровне микрозадач, которые сами по себе полезной функциональности не представляют.
AJ>И при ошибках во взаимодействии этих микрозадач могут возникать ошибки, которые все тесты ни сном ни духом...

Это уже integration testing. А как ты помнишь, TDD включает в себя только unit-testing. Но с другой стороны при обнаружении бага ты можешь написать integration test на него, чтобы он больше не возникал.

И вообще-то, по большому счету, тестирование в TDD не самое важное. Самое важное это Test-First Design, т.е. дизайн, рождающийся благодаря априорному наличию требований, выраженных в коде.

Но так удачно получилось, что требования и unit-testing реализованы в одном лице (в виде unit-тестов). Собственно от тестов с точки зрения именно тестирования требуется лишь хорошее покрытие кода с тем, чтобы без боязни применять refactoring. Который в свою очередь является механизмом поддержки evolutionary design, и если копнуть дальше, то и самого ООП...

Я бы описал сие следующим образом:

TDD = test-first design (requirements) + unit-testing (foundation) + refactoring (evolutionary design) + feedback (justifies refactoring, hence evolutionary design)

Тогда OOP отлично реализуется как object decomposition + TDD.

--

Владимир.