Есть проблема, для которой я никак не могу придумать решение.
Есть сущность, у которой есть 7 разных состояний. Переход по состояниям последовательный, т.е от 1 до 7. При этом, например, из 7 состояния нельзя попасть в 6. Кроме того взяв сущность в состоянии 2 и изменив что-то в базе, мы не превратим его в сущность с состоянием 3. Также невозможно создать сущность в нужном состоянии (только в 1).
Изначально задача стояла проверить, что все работает корректно от создания сущности до 7 состояния, но в таком случае тест получается очень длинным, да и если тест упадет на 1 состоянии, остальные не проверятся. Тогда я разделила все на 7 разных тестов, то есть проверяю только переход от одного состояния в другое. Пользователь с сущностью в нужном состоянии берется из базы. И тогда возникает проблема, что сущности в нужном состоянии могут кончиться
.
Может кто-нибудь сталкивался с таким? У меня очень много таких кейсов, и не первый день ломаю голову.
Пока что придумала только 3 варианта:
оставить как сейчас, т.е. 7 тестов, проверяющих переход из одного состояние в другое, при этом придется закрывать глаза на упавшие тесты из-за отсутствия сущностей
1 длинный тест
7 тестов, но при отсутствии сущности в нужном состоянии брать сущность в предыдущем состоянии и доводить до нужного.
На абстрактном примере довольно сложно подсказать верный подход. Обычно самое простое решение может крыться в деталях.
Исходя из описания, вам нужны 7 независимых тестов. Да, это будет долго, но брать юзера с уже готовой сущностью в нужном состоянии - не совсем корректно. Любое структурное изменение сущности в БД приведет к тому, что ваши preceded data станут невалидными + упомянутый факт, когда готовые сущности могут закончится. Засовывать все проверки в один тест тоже неправильно, т.к. в таком случае определенные фейлы могут сокрывать остальные. Т.е. я бы все же остановился на следующем варианте:
Create entity -> check 1st state.
Create entity -> pass 1st state -> check 2nd state.
Create entity -> pass 1st state -> pass 2nd state -> check 3rd state.
…
Create entity -> pass 1st state -> … -> pass 6th state -> check 7th
state.
При этом, каждый тест должен проверять только свое состояние, а не “на всякий случай проверю наличие иконки на 3м степе”. Да, повторюсь, total execution time возрастет. Но вы меня извините, если брать к примеру многошаговые пеймент системы со сложной ветвистой логикой, так там каждое состояние критично. Нельзя просто скипнуть промежуточный шаг (если он не покрыт отдельно). Зато при таком подходе вы сможете с высокой точностью определять проблемы. Ну а ускорить процесс можно масштабированием. Хотя, опять-таки, я ведь не зря вначале сказал, что сложно давать какие-то советы на абстрактном примере. Как говорится, depends on.
Это называется Pre-condition выполнения теста. То есть перед началом теста должно быть выполнено условие - в базе гарантированно есть хотя бы один пользователь с сущностью в нужном состоянии. Это и надо обеспечить. Также согласен с тем, что написал @ArtOfLife
Может помочь ответ на вопрос: а как это проверять вручную? Какие будут тесткейсы? Распиши и автоматизируй.
P.S. вот почему автоматизатор должен быть прежде всего тестировщиком
Я как раз-таки ручной тестер, который пытается что-то автоматизировать Вручную обычно проверяю все 7 состояний сразу. То есть, если надо проверить 7, то последовательно иду от создания. Просто если я проверяю руками, то я могу как-то обойти ошибку, на которой может зафейлиться тест.
Сейчас я пока сделала так, чтобы тесты запускались в нужной последовательности. Т.е. в идеальном случае у меня всегда будет сущность. + Сделала какое-то количество сущностей со всеми состояниями, но думаю, проблему это не решит. Если тест 10 раз упадет на состоянии 2, то состояние 3 другой тест не проверит.
вариант интересный, но в таком случае все равно получается, что если на 1 состоянии тест падает, то второе проверять мы не сможем.
Вопрос не в том как ты это проверяешь, а в том, как написаны тесткейсы. Или ручной мега-тесткейс это норма? Совсем нет
Когда я говорил гарантированно есть хотя бы один пользователь с сущностью в нужном состоянии я имел ввиду, что тест перед прогоном создает сущности, которыми будет пользоваться. Например. Либо есть заранее подготовленные тестовые данные, которые гарантируют выполнение pre-condition.
Насоздавать заранее кучу пользователей в расчете на то, что даже если часть пропадёт зря, их всё равно хватит, тоже конечно вариант, но он нестабильный, как ты сама заметила
Ну если они жестко взаимосвязаны, то это нормальная ситуация. И сразу открывается блокер, которй должны пофиксить ASAP. Почему в случае фейла нельзя полагаться на уже готовые preceded состояния? Потому что внесенный апдейт кода (вызвавший фейл) может кардинально влиять на весь workflow. Посему нельзя однозначно утверждать, что итоговые результаты (с учетом пропущенного багового состояния) будут валидными. К тому же, как вы будете готовить прекондишены для промежуточных состояний в случае наличия блокера? Еще отмечу, что такое делать опасно, ибо рано или поздно ваши заготовки могут стать out of date, посему тут нужен очень жесткий контроль и постоянный ревью.
В смоук-тесте - да, это один большой тесткейс. Если брать кейсы по этому разделу, то конечно они разбиты на более мелкие части, но все равно. К примеру, кейс звучит так “Пройди состояние 6 с такими-то данными”. Но чтобы пройти состояние 6, нужно до него дойти.
Я думала на эту тему, хотела менять состояние сущности через базу, но проблема в том, что в базе меняется не только id состояния, например, но и кладется json, который нужно сгенерировать, да и разработчики сказали, что из-за манипуляций с состояниями могу быть баги. Остается только вариант, который предложил @ArtOfLife, видимо так и сделаю
testomat.io управление авто тестами
Вручную обычно проверяю все 7 состояний сразу. То есть, если надо проверить 7, то последовательно иду от создания. Просто если я проверяю руками, то я могу как-то обойти ошибку, на которой может зафейлиться тест.