tbd

IdM tests were written with these assumptions:

• Most of method calls are synchronized, so you can call method and return result immediately
• You can make test transactional and rollback it after test finishes

These assuptions enable writing isolated tests, rollbacking DB transaction cleans data (and there's cache clean up processing in case of transaction rollback in default test helper too). It is not perfect, there are ignored tests with note that some other test breaks their data.

With Kafka introduction, both assumptions are false. Kafka was firstly used in notifications and notifications are involved in almost any action. Kafka usage also means you can't encapsulate test into separate DB transaction because Kafka listener reading from DB wouldn't see data written by test transaction. And this means you have to be aware of there can be data in database before test. Or you should clean data manually after every test.

Therefore, ideal test taking new reality into account should:

• NOT use DB transaction
• NOT suppose DB is clean before test start
• clean DB after itself
• create unique entities (e.g. admin_timestamp instead of just admin)
• test existence of its unique entities instead of general entity count
• in case of notifications, reading them by service (and wait for them using waitForResult if needed) instead of relying on fully fresh ones returned by send methods