-Поиск по дневнику

Поиск сообщений в rss_forum_sources_ru

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 29.07.2007
Записей:
Комментариев:
Написано: 80


TDD vs не TDD

Суббота, 05 Сентября 2020 г. 14:28 + в цитатник
korvin:
Цитата D_KEY @
Так вот вопрос, эти более ранние тесты становятся интеграционными? Ведь у каждого юнита появится свой тест.

Не обязательно, зависит от архитектуры. У тебя же высокоуровневая задача является некоторой композицией низкоуровневых, вот смотри, в моём примере, я переделал высокоуровневый сервис (относительно Accounts, Transactions, Compliance, Notifier) Transfer, чтобы он не включал зависимости внутрь себя, т.е. вместо
    Transfer
    + Accounts
    + Transactions
    ...

получилось
    Composer
    + Transfer
    + Accounts
    + Transactions
    ...

где Transfer хоть и реализует высокоуровневую логику посредством остальных компонентов, но расположен на том же (структурном?) уровне фактически.
Composer в свою очередь может быть абстрактным и тривиальным и иметь свои юнит-тесты. Естественно, можно сделать и интеграционные тесты (они ж не взаимозаменяемы с юнит-тестами), а на самом-самом верхнем уровне ещё добавить функциональные/end-to-end/системные тесты.

Добавлено
Ну, собственно, если у тебя правильная инверсия зависимостей, то высокоуровневый модуль полностью независим от низкоуровневых и ты можешь писать нормальные юнит-тесты для него )

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838340

Метки:  

 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку