@nexedi Here is the commit message explaining the rationale behind this change on runUnitTest behavior when passing --save and when not passing --load --save arguments:

Assuming that the test database already exists and 'movement' table already contains data (from past execution for example), on '--save' before this commit:

1. Create a new ERP5 Site:
   1. Install erp5_mysql_innodb_catalog.
   2. Call ERP5Site_reindexAll(clear_catalog=True) (from ERP5Generator.setupIndex()). => At this point, erp5_mysql_innodb_catalog tables are recreated.
2. Install erp5_movement_table_catalog or any bt5 adding a new SQL table. => This does not recreate the table and leave the existing data as it is.
3. Dump MySQL database to dump.sql. => dump.sql contains 'INSERT INTO' for 'movement' table before this '--save'.

This fixes random customer Unit Tests failures on SQL queries accessing 'movement' table directly and getting {non-existing,past executions} Movements.

With this commit, after installing all bt5, all tables handled by the Catalog will be cleared and ERP5Site_reindexAll will be called.``

The reasons why I have created a merge request instead of merging it directly:

• Objects will be indexed on bt5 installation and again at the end through ERP5Site_reindexAll, thus this will have an impact on erp5testnode (by how much I don't know though).
• Still not a perfect solution as it does not clean everything (for example if one test installs a table and the next execution does not, it will not be removed). On the other hand, clearing all tables of the test database is probably a problem too if we consider there could be tables not handled by ERP5 itself.