В настоящее время я работаю над реализацией тестового набора для относительно сложного приложения. Приложение основано на Java и Spring с веб-интерфейсом. Фронтенд-тесты могут быть написаны также на Java (с использованием Silk4J и их клиента автоматизации). На самом деле написание тестов не проблема, это легкая часть. Там, где он начинает усложняться, это порядок, в котором могут выполняться отдельные тесты.
В настоящее время мы пишем наши тесты, используя JUnit. Поскольку JUnit - это инструмент модульного тестирования, порядок выполнения тестов не является фиксированным. Если мы просто создадим тесты для каждого модуля приложения, мы быстро столкнемся с проблемами. Некоторые тесты должны полагаться на другие части, чтобы они работали правильно и чтобы были доступны определенные данные из других модулей. Я мог бы написать тесты для каждого модуля таким образом, чтобы инициализировать состояние приложений до предварительно определенного состояния, а затем выполнять его тесты, но очистка и подготовка состояния была бы довольно трудоемкой задачей. Более сложные тесты требуют огромного количества подготовительных и тестовых сценариев для нескольких модулей.
То, что я ищу, - это среда тестирования, в которой каждый тест может как-то определить свои требования и какой сервис он тестирует / предоставляет (тестирование функции create-user-фактически может создавать пользователей ... по крайней мере, это должен). Теперь я не хочу жестко программировать, какой тест выполняется с какими данными и в каком порядке, потому что очень сложно определить порядок и изменения в приложении, что потребовало бы полного рефакторинга тестов.
Например, мой «create-user-test» создает пользователей как побочный эффект фактической проверки, что пользователи созданы правильно. Для меня не имеет значения, проверяется ли эта функциональность с использованием userA, userB или userC, до тех пор, пока она проверяется. Если у меня теперь есть другой тест «create-account-test», который требует, чтобы пользователь, который удовлетворял только userC, то тестовая система должна знать: «О ... create-account-test нужен userC, который еще не был создан, но путем передачи userC для моего "create-user-test", который бы его создал. Таким образом, в конечном исполнении он запускает "create-user-test" с userC перед "create-account-test" и тем самым использует побочный эффект "create -user-test "для создания состояния, необходимого для" create-account-test ".
Проверяя требования и услуги моих тестов. Такая система должна быть способна создавать нециклический граф, содержащий каждый тест, по крайней мере, один раз (тем самым тестируя всю функциональность), но без необходимости подготавливать / разбирать состояние приложений для каждого теста или выдавать ошибку, если по каким-либо причинам невозможно создать такой график. По крайней мере, так я мог бы создать огромные тестовые сценарии, которые по-прежнему оставались бы в обслуживании.
Я знаю, что это несколько сложно. Я погуглил некоторое время, если кто-то уже работал над такой структурой. К сожалению, я не смог найти ничего похожего.
Теперь я надеюсь, что кто-то здесь, чтобы привести меня к инструменту ИЛИ сказать мне, почему это совершенно плохая идея. Ответ "Эй ... отличная идея ... никто еще не создал такую вещь" ... наверняка резко убил бы мое свободное время после работы, потому что в этом случае я вероятно начал бы разрабатывать такой инструмент; -)
Chris