юнит тестами? И как наполняете embedded базу - в одном месте всю, или в каждом тесте отдельно?
посмотрел в паре проектов, в одном проекте лежат вместе с юнит-тестами, в другом выделены в отдельный модуль - так сразу и не скажешь что лучше. По поводу БД точно также есть про и контра, с одной стороны сгенерить один раз бд и прогнать все тесты - тесты будут выполнятся быстрее, но зато появляется риск взаимного влияния тестов через данные в бд. Тема раскрыта в книге https://ru.scribd.com/doc/240943920/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D1%8B-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-xUnit-pdf
Зависит от кол-ва тестов, для микросервиса можно все вместе, для монолита - придется разделять, там тесты могут и часами идти. База синглтон паттерн, каждый тест независимый.
Про базу синглтон и независимые тесты не совсем понял. Вот у меня например embedded mongo. При старте тестов поднимается и работает пока все тесты не пройдут. Если я заинсерчу в каком -то тесте что-то, то в другом тесте это появиться. Выглядит что есть пара решений 1. На каждый тест поднимать заново базу - так себе вариант 2. Заполнить базу всеми данными при старте - но потом инсерты делиты все равно будут ее менять 3. В каждом тесте откатывать изминения. Заинсертил, после прохожления теста сделал делит.
Синглтон-контейнер - 1 база на все тесты Тесты независимы, у тебя есть @BeforeEach/@AfterEach, тут подчищаешь.
Да, выглядит что надо подчищать, так честнее всего. Хотя тестируются еще и метды очистки посути
1. Рабочий вариант, если база быстро поднимается. 2. Вот тут есть риск что 5-й тест как-то неправильно поломает данные, которые потом будет использовать 37-ой тест. 37-й упадёт и вы будете долго искать почему он упал. 3. Вполне рабочий. Есть такой приём - при старте теста открыть транзакцию, в конце абортировать -база вернется в исходное состояние. Применить можно не всегда - зависит от логики вашего приложения.
Обсуждают сегодня