Сообщение Re[64]: Что такое Dependency Rejection от 22.02.2024 21:54
Изменено 22.02.2024 23:28 ·
Re[64]: Что такое Dependency Rejection
Здравствуйте, Sinclair, Вы писали:
S>Теперь остаётся всё это склеить. Риск при склейке минимален — просто потому, что в ней очень мало кода:
S>Я не отказываю этому коду в шансе содержать ошибку — действительно, мы могли напороть примерно везде.
По-моему я не донёс эту мысль. Да, совершенно верно: "Риск при склейке минимален — просто потому, что в ней очень мало кода". Настоящая проблема в том, что тут у нас как правило не одна "плохая зависимость" как DateTime.now(); и этот код склейки будет в каждой мелкой бизнес-операции приложения. Т.е. в каждом контроллере мало кода, да, но в реальной большой системе зависимостей будет больше, контроллеров сотни-тысячи, этот "минимальный риск" надо возводить в тысячную степень и ВНЕЗАПНО риск получается серьёзным, и тестами прикрыть себе пятую точку не выйдет, т.к. "DateTime.now()" не тестируемо.
Суть всех этих модулей, слоёв, composition root, &c — минимизировать общее количество такого кода склейки. И максимизировать покрытие тестами в том числе и кода склейки.
S>Такие вещи ловятся интеграционным тестированием, которое один хрен нужно проводить.
А что ты в таком тесте, зависящем от DateTime.now() будешь ассертить? Ведь каждый раз у тебя будут выдаваться потенциально совершенно разные результаты. Ну выдался отчёт с 0 строк — тест пройден или как?
S>Теперь остаётся всё это склеить. Риск при склейке минимален — просто потому, что в ней очень мало кода:
S>DateTime.now()
S> .GetReportDateRange()
...S>Я не отказываю этому коду в шансе содержать ошибку — действительно, мы могли напороть примерно везде.
По-моему я не донёс эту мысль. Да, совершенно верно: "Риск при склейке минимален — просто потому, что в ней очень мало кода". Настоящая проблема в том, что тут у нас как правило не одна "плохая зависимость" как DateTime.now(); и этот код склейки будет в каждой мелкой бизнес-операции приложения. Т.е. в каждом контроллере мало кода, да, но в реальной большой системе зависимостей будет больше, контроллеров сотни-тысячи, этот "минимальный риск" надо возводить в тысячную степень и ВНЕЗАПНО риск получается серьёзным, и тестами прикрыть себе пятую точку не выйдет, т.к. "DateTime.now()" не тестируемо.
Суть всех этих модулей, слоёв, composition root, &c — минимизировать общее количество такого кода склейки. И максимизировать покрытие тестами в том числе и кода склейки.
S>Такие вещи ловятся интеграционным тестированием, которое один хрен нужно проводить.
А что ты в таком тесте, зависящем от DateTime.now() будешь ассертить? Ведь каждый раз у тебя будут выдаваться потенциально совершенно разные результаты. Ну выдался отчёт с 0 строк — тест пройден или как?
Re[64]: Что такое Dependency Rejection
Здравствуйте, Sinclair, Вы писали:
S>Теперь остаётся всё это склеить. Риск при склейке минимален — просто потому, что в ней очень мало кода:
S>Я не отказываю этому коду в шансе содержать ошибку — действительно, мы могли напороть примерно везде.
По-моему я не донёс эту мысль. Да, совершенно верно: "Риск при склейке минимален — просто потому, что в ней очень мало кода". Настоящая проблема в том, что тут у нас как правило не одна "плохая зависимость" как DateTime.now(); и этот код склейки будет в каждой мелкой бизнес-операции приложения. Т.е. в каждом контроллере мало кода, да, но в реальной большой системе зависимостей будет больше, контроллеров сотни-тысячи, этот "минимальный риск" надо возводить в тысячную степень и ВНЕЗАПНО риск получается серьёзным, и тестами прикрыть себе пятую точку не выйдет, т.к. "DateTime.now()" не тестируемо.
Суть всех этих модулей, слоёв, composition root, &c — минимизировать общее количество такого кода склейки. И максимизировать покрытие тестами в том числе и кода склейки.
S>Такие вещи ловятся интеграционным тестированием, которое один хрен нужно проводить.
А что ты в таком тесте, зависящем от DateTime.now() (и ещё пачки внешних зависимостей в неизвестном тесту состоянии) будешь ассертить? Ведь каждый раз у тебя будут выдаваться потенциально совершенно разные результаты. Ну выдался отчёт с 0 строк — тест пройден или как?
S>Теперь остаётся всё это склеить. Риск при склейке минимален — просто потому, что в ней очень мало кода:
S>DateTime.now()
S> .GetReportDateRange()
...S>Я не отказываю этому коду в шансе содержать ошибку — действительно, мы могли напороть примерно везде.
По-моему я не донёс эту мысль. Да, совершенно верно: "Риск при склейке минимален — просто потому, что в ней очень мало кода". Настоящая проблема в том, что тут у нас как правило не одна "плохая зависимость" как DateTime.now(); и этот код склейки будет в каждой мелкой бизнес-операции приложения. Т.е. в каждом контроллере мало кода, да, но в реальной большой системе зависимостей будет больше, контроллеров сотни-тысячи, этот "минимальный риск" надо возводить в тысячную степень и ВНЕЗАПНО риск получается серьёзным, и тестами прикрыть себе пятую точку не выйдет, т.к. "DateTime.now()" не тестируемо.
Суть всех этих модулей, слоёв, composition root, &c — минимизировать общее количество такого кода склейки. И максимизировать покрытие тестами в том числе и кода склейки.
S>Такие вещи ловятся интеграционным тестированием, которое один хрен нужно проводить.
А что ты в таком тесте, зависящем от DateTime.now() (и ещё пачки внешних зависимостей в неизвестном тесту состоянии) будешь ассертить? Ведь каждый раз у тебя будут выдаваться потенциально совершенно разные результаты. Ну выдался отчёт с 0 строк — тест пройден или как?