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

__>Т.е. для любой последовательности изменений в рамках TDD существует последовательность изменений в рамках традиционных диаграмм в стиле UML. Только в случае с UML в результате получается проектная документация, а не юнит-тесты.
Как там говорилось?.. Популярность UML стала падать после того, как некоторые осознали, что неправильные диаграммы дают неправильный код.
Во-первых, с проектной документацией и диаграммами на бумаге есть серьёзная проблема: не существует способа проверить соответствие кода и документации. В документации может говориться одно, а работать оно может совершенно по-другому. Что делает ценность такой документации отрицательной — тратишь время на изучение, а потом выясняется что на самом деле всё не так. Набор юнит-тестов это по сути и есть проектная документация — но гарантированно правильная документация — формально проверяемая.
Во-вторых, диаграммы на бумаге очень плохо переживают изменение требований, что является необходимым в реалиях современной разработки ПО.
В-третьих, TDD не запрещает рисовать диаграммы — рисуй, если это действительно привносит какую-то ценность в проект. Обычно так и делают, но такие диаграммы требуются только на достаточно высоком уровне описания проекта, а юнит-тесты, например, могут описывать конкретную реализацию мельчайших модулей, под которую бумаги не хватит всё описывать.

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

__>Т.е. для любой последовательности изменений в рамках TDD существует последовательность изменений в рамках традиционных диаграмм в стиле UML. Только в случае с UML в результате получается проектная документация, а не юнит-тесты.
Как там говорилось?.. Популярность UML стала падать после того, как некоторые осознали, что неправильные диаграммы дают неправильный код.
Во-первых, с проектной документацией и диаграммами на бумаге есть серьёзная проблема: не существует способа проверить соответствие кода и документации. В документации может говориться одно, а работать оно может совершенно по-другому. Что делает ценность такой документации отрицательной — тратишь время на изучение, а потом выясняется что на самом деле всё не так. Набор тестов это по сути и есть проектная документация — но гарантированно правильная документация — формально проверяемая.
Во-вторых, диаграммы на бумаге очень плохо переживают изменение требований, что является необходимым в реалиях современной разработки ПО.
В-третьих, TDD не запрещает рисовать диаграммы — рисуй, если это действительно привносит какую-то ценность в проект. Обычно так и делают, но такие диаграммы требуются только на достаточно высоком уровне описания проекта, а юнит-тесты, например, могут описывать конкретную реализацию мельчайших модулей, под которую бумаги не хватит всё описывать.