Новое сообщение в форум Архитектура программного обеспечения

Форум	Архитектура программного обеспечения
Тема	Как правильно задавать вопросы

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

P>Здравствуйте, Буравчик, Вы писали:

Б>>Ну, у тебя (будем на ты?) то же самое написано. У тебя тяжелые зависимости вынесены в функции, а у меня вынесены в отдельные классы, закрыты интерфейсами (они в дальнейшем и мокаются), передаются как параметры.

P>Почти то же самое. Вам нужно мокать репозиторий, а мне всего то лямду подкинуть.

Б>>Моки позволяют отрезать эти тяжелые вычисления и заменить их на простое поведение для теста.

P>Вопрос в том, сколько вам кода для этих моков надо. Если у вас, скажем, три раза подряд идет вызов [tt]repo.get[/tt] вам придется заниматься глупостями - 
P>писать чтото навроде [tt]OnCall(3).Returnо(that)[/tt] или писать кастомную вещь.

P>Собственно я вам привел пример, как вроде бы те же моки можно свести к простым тестам. Кода для моков около нуля, в отличие от вашего варианта.

Б>>Стабы/моки - вопрос терминологии. Я называю моками все разновидности моков, а стабами те, которые работают как "функция" - получили результат, обработали, вернули нужны.

P>Стабы подкидывают значения. Моки - это тесты вида "проверить, что вызвали то и это"

Б>>Моки, для которых проверяется факт вызова "с параметров а-б-в", тоже изредка могут применяться в основном для проверки отправки сообщений, где ответ не важен (в кафку, аудит).

Б>>Про дизайн. Подход с моками как раз не навязывает дизайн (не вынуждают выделять функции).

P>Наоборон - моками вы бетонируете конкретный дизайн. Там где вы тестами на моках проверяете что repo.get вызвался с тем или иным параметром, изменить дизайн на другой вы можете только через поломку всех таких тестов. Даже если просто укажете, что "функция использует репозиторий", у вас будут поломки на ровном месте из за смены дизайна.
P>То еть - моки ограничивают вас в выборе

Б>>Где уместно, я создам чистую функцию и тесты (обычно для алгоритмов бизнес-логики). Где не уместно - буду использовать моки (обычно для логики приложения).
Б>>Т.е. любую сложную логику при желании могу протестить юнит-тестами

P>И тесты и дизайн кода влияют друг на друга. Если вы избавитесь от моков, внезапно окажется, что можно менять дизайн, а не бояться, что надо перебулшитить все тесты.

Б>>Они у меня эти зависимости отделены. Выделены в отдельные классы (репозитории и т.п.), прокидываются как параметры.

P>>>Теперь в тестах вы можете создать n троек значений, m  результатов операций
P>>>И покроется все одной таблицей тестов n x m

Б>>Как тест будет написан? Как подготовлен, как будут передаваться эти n x m, как проверен?

P>Нам нужно описать все значения, табличкой. Часть значений протаскиваются через параметры, часть - через лямбды.
P>У нас их шесть штук, v1,v2,v3, repo1, svc, repo2,
P>Дальше у вас будет один параметризованый тест типа такого, не знаю как на вашем питоне это выглядит, напишу на жээсе

P>[code]
P>@test()
P>@params(
P>	1,2,3,4,5,6  // и так на каждую строчку в табличке
P>)
P>@params(
P>	8,4,2,1,3,5 // точно так же и исключения прокидывают
P>)
P>...   сколько строчек, столько и тестов фактически выполнится
P>"a cool name test name" (v1, v2, v3, repo1, svc, repo2, result) {
P>   let logic = Logic(v1,v2,v3);

P>   let r = logic.run({
P>      load: () => repo1,
P>      load2: () => svc,
P>      ... и так прокидываем все что надо
P>   })

P>   expect(r).to.deep.eq(result)
P>}
P>[/code]

P>>>Любители моков правда очень обрадуются, умножат(sic!) Количество тестов за счет проверок "commit вызывается после двух load"

Б>>Это твое (неправильное) понимание

P>Это типичная картина, к сожалению. Еще могут оставить только такие тесты.

P>>>Теперь ваш мок repo.get должен считать вызовы - что его вызвали первый раз с v1, второй раз с v2, и это важно, т.к на втором разе вы должны вернуть кое что другое
P>>>И это именно то, чего делать не стоит - в сложной логике ваш мок репозитория будет чудовищем, которое мало будет походить на реальную часть системы
P>>>Чем более унивесальная зависимость, тем труднее её мокать, и тем выше шансы на ошибку

Б>>Для этого теста (который будет проверять эту ветку логики) для операции repo.get будет написан такой стаб:

Б>>[code]
Б>>if v1:
Б>>  return value1
Б>>else if v2:
Б>>  return value2
Б>>else:
Б>>  raise
Б>>[/code]

P>а нам всего то надо подкинуть два значения
P>[code]
P>() => value1
P>() => value2
P>[/code]

Б>>Да, выглядит компактно и понятно. И никто не заставляет наворачивать дизайн как у тебя - с дополнительными функциями, от которых код становится сложнее.

P>А я вас и не заставляю :-) Большей частью у меня получается избавиться от моков, заменить на проверку значения или состояния. Они самые дешовые, их можно за короткое время настрочить десятки и сотни.

Б>>Зависимости отделены также, как и у тебя. В твоем случае в тесты ты передаешь их как параметры-функции, а я подменяю поведение через стаб (по-сути ту же функцию). И в обоих случаях проверяются все варианты

P>Ну так посмотрите - у меня две строчки, у вас шесть.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail