Форум
Архитектура программного обеспечения
Тема
Как правильно задавать вопросы
B
I
abc
U
X
3
X
3
H1
H2
H3
H4
H5
H6
Asm
C/C++
C#
Erlang
Haskell
IDL
Java
Lisp
MSIL
Nemerle
ObjC
OCaml
Pascal
Perl
PHP
Prolog
Python
Ruby
Rust
SQL
VB
Здравствуйте, Буравчик, Вы писали: Б>Здравствуйте, Pauel, Вы писали: P>>Если дизайн именно такой, и надо вдруг покрыть это тестами, то вариантов не много P>>1. интеграционные тесты с какой то базой P>>2. разного сорта моки Б>Что значит дизайн такой? Это логика приложения такая, как ее по другому задизайнить? P>>для п.2 для разработчиков очень трудно не скатиться в тавтологические тесты вида "метод вызывает другой метод" Б>С моками можно по-разному тестировать. Правильно - в моках возвращаемое значение фиксировать, а не тестировать факт вызовы. Б>Хотя в некоторых случаях и факт вызова тоже может быть важен P>>Это ничего не меняет - вашем дизайне вариантов нету, и наличие ветвлений их не увеличит. Б>Не понял, что понимается под вариантами. И почему ветвления не влияют. P>>Проблема в самих зависимостях, их много, и в том, что ваш дизайн мутабельный P>>Попробуйте отказаться от мутабельного дизайна. Как минимум, три эффекта из четырех легко отделяются. Так что можно упростить до безобразия. Б>Я как раз и хочу понять, как эту логику сделать иммутабельной, чтобы все варианты протестить. Б>Как выделить эффекты, можно продемонстрировать? Б>С моками (стабами) я понимаю как это сделать - сайд-эффекты выделяются в интерфейсы (repo, external_service), мокаются, и далее вся логика проверяется как обычный юнит-тест.
Теги:
Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например:
"Visual Studio" .NET
Имя, пароль:
Загрузить
Нравится наш сайт?
Помогите его развитию!
Отключить смайлики
Получать ответы по e-mail
Проверить правописание
Параметры проверки …