Comments 7
Таков дизайн JUnit framework. В аннотациях @BeforeEach не предоставляется информация к какому тестовому методу он относится. Поэтому JUnit выполняет его для всех тестовых методов определённых в классе.
Ну тут автор несколько лукавит. Junit5 предоставляет возможность подставлять в предУсловие (@BeforeEach) и в постУсловие (@BeforeAll) объект TestInfo, в котором как видно из названия, хранится информация о тесте. Пример:
@BeforeEach
public void precondition(TestInfo testInfo) { ... }
И в документации об этом сказано.
Скопировать скаченный JAR файл в директорию
libs.
Какой-то колхоз!) Завёл https://github.com/DarrMirr/dbchange/issues/1
А за статью большое спасибо; взял себе на заметку.
Если используете Spring Framework, то там есть аннотация `@Sql`, которая решает сходные задачи. Не пробовали смотреть, как у них сделано? Было бы интересно почитать про преимущества и недостатки :-)
Широко использовал во многих проектах аннотацию `@Sql`. Но я столкнулись с проблемой при использовании такого решения: сложно поддерживать sql запросы, которые кодируются текстом. Для себя я выявил следующие недостатки такого подхода:
- сложно переиспользовать sql запросы
- сложно кастомизировать sql запросы с помощью параметров
- при частом изменении схемы править приходится большое количество sql запросов
- не очевиден порядок выполнения sql запросов
- необходимо в insert sql запросе обязательно указывать все not null значения, что в итоге приводит к не пониманию, а какие именно значения нужны для теста
- как бы странно не звучало, не все проекты написаны на Spring Framework
Я искал решение, которое бы могло покрыть все описанные выше недостатки, но к сожалению не нашёл. Поэтому написал DbChange. Изначально в нём была возможность только задать changeset (через Java классы). Но потом я подумал, что у решения предлагаемого Spring Framework тоже есть плюсы и кому-то это может быть полезным. И потом уже добавил поддержку statements и sqlQueryFiles.
Я намерено в статье не ссылался на Spring Framework, т.к. библиотека не позиционируется как альтернатива его аннотации `@Sql`. Хотя вы верно отметили, что часть функций схожа. Вы можете использовать любую из них или обе сразу. Это ваш выбор. Но в любом случае, спасибо, что обратили на это внимание. На мой взгляд, важно предоставить разработчику набор инструментов, чтобы он уже сам выбрал подходящий для решаемых задач.
Постоянно сталкиваюсь с тестирование БД в JVM проектах и DBUnit со своими обертками поверх него всегда помогал! Может кому из читателей пригодится Database Rider
Введение в DbChange JUnit расширение