Testing the migration requires manually resetting the target database to delete migrated data.

Solution:
Especially if #4 is implemented, target connections databases could reset themselves in development, if a SQL script is provided.

UPDATE 2021-05-17:
Tests using a database can extend AbstractDbalTestCase. It still resets manually.
A test has been made to use an in-memory SQLite database but the DBAL platform does not support foreign key constraints and is incompatible with the foreign key feature as mentionned in ForeignKeyBeforeTask.

Leaving open until doctrine/dbal#4288 is fixed

Migrators are registered and executed in the order they are listed in the migrators config key or in alphabetical order with the migrators_directory key.
The later will break some (if not most) apps with foreign key constraints that need to be migrated.

Solution:
Add a method to list migrators that need to be executed before the current one. The best would be to auto-order but not sure it can be done.

Actually, testing is hard:

• Fregata mostly provides abstractions
• some abstractions cannot be mocked (need properties, ...)
• implementations are either saved froma string into a virtual filesystem or anonymous classes
• creating tables "on the fly" is a bit painful

This needs a big refactoring work to make testing Fregata a breeze.

$tableName parameter

Why was it useful in v1

The $tableName parameter of the constructor is required because of doctrine/dbal#4506 which prevents getting the local table from a ForeignKeyConstraint.
This issue is now closed and the circular reference has been removed, deprecating the use of ForeignKeyConstraint::getLocalTableName() among other methods.

Actually the internal and user code have to use the SchemaManager to get the table.

How to replace it in v2

Replacing the string $tableName parameter with a Table $table one would only require the user to provide the object. The parameter count would be the same but it would enforce a better type for the ForeignKey class and remove most of the SchemaManager usage in ForeignKeyBeforeTask and ForeignKeyAfterTask.

$allowNull parameter

Why was it useful in v1

This parameter is required to reset a column of a foreign key constraint back to NOT NULL after a migration, during an after task. This is necessary because some of the columns of a foreign key constraint may accept NULL. This parameter helps keeping track of the columns that were NOT NULL before the migration.

How to replace it in v2

Storing the columns that should be set back to NOT NULL using a cache system. The $allowNull parameter could simply be removed.

Migrations should be tested in a development environment and then run on production databases. Switching from one environment to another requires manually change the connections properties.

Solution (suggestion):
Manage environment with .env files ?

In the Configuration class, to get all the migrators in a directory, it parses PHP tokens in files manually. Could seem like reinventing the wheel.

Solution:
Replace with an external library, maybe Roave/BetterReflection.