Последние комментарии

Михаил Фленов

OpenSource далеко не всегда коммерческое, как раз очень редко оно коммерческое. Просто OpenSource не исключает коммерцию, она разрешена.

Overdrive

Но и раньше был не 8 часовой рабочий день (в некоторых странах уже есть 6 часовой). Поэтому далеко не факт, что производительность упала, может наоборот даже возросла. Надо считать, так как он многих факторов зависит.

Владимир

Вы часто путаете OpenSource и FreeSoftware. А FreeSoftware не отличаете от FreeWare.

OpenSource - это коммерческое программное обеспечение, где разрешают посмотреть исходники, не не дают на них прав.

FreeWare - это, внезапно, тоже коммерческое программное обеспечение, но за него не требуют денег, не дают смотреть исходники, не дают на программу никаких прав.

FreeSoftware - программное обеспечение, которое может быть как коммерческим, так и не коммерческим. Ключевой момент - пользователю программы предоставляются полные исходные тексты полученной программы, с которыми пользователь может делать всё, что ему угодно. Может раздавать бесплатно, может редактировать по своему усмотрению, а может даже и продавать.

Из контекста этой статьи ясно, что речь идёт не об OpenSource, а о FreeSoftware.

Евгений

Очень справедливые размышления.

Показать - не значит дать пощупать.

Михаил Фленов

Я не заметил цепочки. Есть один модуль с одним классом, который называют крутым словом engine, но он простой - запрос на получение людей, которые сделали какое-то действие. Да, у меня есть подготовительные вещи, типа создания определения, но я даже не проверяю, правильно ли создана конфигурация. Я прогоняю один и тот же метод Process в одном и том же классе, который назвали XXXXPromotion несколько раз и смотрю результат в одном и том же тесте. Там есть и другие XXXXPromotion классы с таким же Process методом, которые делают примерно подобные вещи. Но факт остается фактом, что я тестирую один метод.

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

Overdrive

2Михаил Фленов
Так это уже интеграционный тест. Юнит тест когда проверяется только один модуль и только его функциональность и зависимые объекты поменяются моками в DI контейнере. А так ты получается тестируешь всю цепочку бизнес-логики. Если у приложения плохой дизайн, обычно проблематично написать юнит тесты, и в основном пишутся одни интеграционные.

Михаил Фленов

У меня тестыине могут зависеть друг от друга, потому что выполняются в транзакции и после их выполнения данные не сохраняются в базе.

На примере уже упомянутого мной промоушн движка, как я тестирую простой success path:

1. Создать транзакцию
2. Truncate table с действиями пользователя
3. Создать объявление промоушена
4. Прогнать промоушн
5. Assert на результирующие данные, чтобы убедится, что никто не получил призов, ведь действий пользователя нет
6. Добавить действия
7. Прогнать промоушн и убедится, что приз получен
8. Прогнать промоушн и убедится, что нет дубликата

Кто-то может сказать, что я тестирую три разве вещи:
1. Никто не получает при отсутствии данных
2. Реальный success path
3. Тест на дубликат

Но если их разделить на три, я же не упрощу себе жизнь. Если ошибка будет в первом, то рухнут все три и мне от этого проще искать реальную проблему не будет

Ну в конце у меня конечно же rollback и ничего в базе не остаётся.

he

Как я делаю : ставлю столка ассерт штоби легко можна понят где ошибка. Если из теста трудно понят где ошибка, тест нада изменит

Kastor

Asserts может быть несколько, но они должны тестировать один сценарий.
Главное правило такое - упал один тест - у нас одна проблема. Упало два теста - две проблемы.

Михаил, судя из твоей заметки мне показалось, что твои тесты больше интеграционные, чем модульные. Ты как то разделяешь эти два вида тестов?

А еще мне показалось, что у тебя одни тесты зависят от других. Так ли это?