Flyway don’t clean database correctly, and execute migration files two times

I’m using flyway for migration database, as well I use FlywayTest for my integration tests, but When I create a test using :

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest(classes = APPApplication.class)
@Rollback
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class, FlywayTestExecutionListener.class})
@FlywayTest
public class RolesRepositoryTest {
   ...
}

I get this error :

o.f.c.internal.license.VersionPrinter    : Flyway Community Edition 6.0.8 by Redgate
com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
o.f.c.internal.database.DatabaseFactory  : Database: jdbc:h2:mem:testdb (H2 1.4)
o.f.c.internal.database.base.Database    : Flyway upgrade recommended: H2 1.4.200 is newer than this version of Flyway and support has not been tested. The latest supported version of H2 is 1.4.199.
o.f.core.internal.command.DbValidate     : Successfully validated 4 migrations (execution time 00:00.055s)
o.f.c.i.s.JdbcTableSchemaHistory         : Creating Schema History table "PUBLIC"."flyway_schema_history" ...
o.f.core.internal.command.DbMigrate      : Current version of schema "PUBLIC": << Empty Schema >>
o.f.core.internal.command.DbMigrate      : Migrating schema "PUBLIC" to version 1 - CREATE FIRST TABLES
o.f.core.internal.command.DbMigrate      : Migrating schema "PUBLIC" to version 2 - INSERT ROLES
o.f.core.internal.command.DbMigrate      : Migrating schema "PUBLIC" to version 3 - INSERT ADMINS
o.f.core.internal.command.DbMigrate      : Migrating schema "PUBLIC" to version 4 - INSERT OTHERS
o.f.core.internal.command.DbMigrate      : Successfully applied 4 migrations to schema "PUBLIC" (execution time 00:00.464s)
o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default]

o.f.test.FlywayTestExecutionListener     : ---> Start reset database for  'com.name.project.infrastructure.database.jpa.RolesRepositoryTest'.
o.f.c.internal.database.base.Database    : Flyway upgrade recommended: H2 1.4.200 is newer than this version of Flyway and support has not been tested. The latest supported version of H2 is 1.4.199.
o.f.core.internal.command.DbClean        : Successfully cleaned schema "PUBLIC" (execution time 00:00.010s)
o.f.c.internal.database.base.Database    : Flyway upgrade recommended: H2 1.4.200 is newer than this version of Flyway and support has not been tested. The latest supported version of H2 is 1.4.199.
o.f.core.internal.command.DbValidate     : Successfully validated 4 migrations (execution time 00:00.023s)
o.f.c.i.s.JdbcTableSchemaHistory         : Creating Schema History table "PUBLIC"."flyway_schema_history" ...
o.f.core.internal.command.DbMigrate      : Current version of schema "PUBLIC": << Empty Schema >>
o.f.core.internal.command.DbMigrate      : Migrating schema "PUBLIC" to version 1 - CREATE FIRST TABLES
o.f.core.internal.command.DbMigrate      : Migration of schema "PUBLIC" to version 1 - CREATE FIRST TABLES failed! Please restore backups and roll back database and code!
o.s.test.context.TestContextManager      : Caught exception while invoking 'beforeTestClass' callback on TestExecutionListener [org.flywaydb.test.FlywayTestExecutionListener@797b0699] for test class [class com.name.project.infrastructure.database.jpa.RolesRepositoryTest]

org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateException: 
Migration V1__CREATE_FIRST_TABLES.sql failed
--------------------------------------------
SQL State  : 42S01
Error Code : 42101
Message    : Table "ROLES" already exists; SQL statement:

If you not :

---> Start reset database for  'com.name.project.infrastructure.database.jpa.RolesRepositoryTest'.

This comes from FlywayTestExecutionListener.class but it migrate the database again.

Why flyway do this, and how can stop this.

More details

The problem is not happen when I don’t use schema names in my tables. every thing work fine.

Answer

If you’re reusing FlywayTestExecutionListener on every test, then the setup will be executed per every class with the @TestExecutionListeners, even if you use beforeTestClass.

In JUnit, a way to setup resources for a set of tests a single time is to define a Rule (for Unit 4) and Extensions (for JUnit 5).