Development

[Jotschi]

• Add JUnit 4 Testrule
• Tmpfs Monitoring
• Maybe remove DB settings from start goal since pool and start can be chained.
• Add parameter to configure testprovider container image in mvn plugin.
• Setup release process
• Use mvn plugin to build/push provider image
• Test client error handling
• Check whether tests can access the provider settings in a multi-module maven build
• Document and implement support for update handling of the templateName
• Add template update process
• Reduce dependency of junit artifacts
• Minimal example
• Complex multi module example
• Standalone / dedicated example
• Add load handling during startup
• Implement pool reaper / auto purge (expire)
• Add pool purge to stop mvn command.
• Store randomized poolId in config to allow for multiproject/multibranch setup in standalone/decicated setups
• Assert static rule works as expected

[prdoyle]

Hi @Jotschi. This project looks intriguing, but I'm not totally clear on how it actually saves time. Each test still needs a database to be created and initialized, right?

[Jotschi]

@prdoyle

Nope, each test will get a ready made database. The preparation of the databases is done async in the background by a server which runs along with the database.
Thus multiple tests can directly utilize a ready-made db without need to prepare and setup the test fixture.

Additionally no database server needs to be spun up (e.g. when using testcontainers).

There are multiple ways to setup the server and initialize the template database that is being used for cloning the DB's that are handed out to tests. I prefer using the stand-alone docker option but maven would also work fine.

I hope this clarifies the way it works.

[prdoyle]

I think so. So there are two sources of efficiency:

1. In some cases, multiple tests can use the same database, presumably if they don't modify it in a way that interferes with the other tests.
2. In all cases, the databases are created and initialized asynchronously and efficiently.

Am I close?

[Jotschi]

@prdoyle

1. In some cases, multiple tests can use the same database, presumably if they don't modify it in a way that interferes with the other tests.
   Multiple tests could use the same DB but I would always use a fresh DB because I would not trust myself or the code that it will not taint the database. In case of this project tests should all use the provided db. No need to reuse a db.
2. In all cases, the databases are created and initialized asynchronously and efficiently.
   Yes, essentially the database in the DB server is already prepared before a test needs it.

[prdoyle]

Ah so it's more #2. Cloning up new databases is quicker than initializing them via application code.

[Jotschi]

@prdoyle
Yes it is especially faster with the postgres database template functionality.
https://www.postgresql.org/docs/current/manage-ag-templatedbs.html
Pair this with disabled fsync in the DB + a tmpfs for storage and it is super fast.

[prdoyle]

Ah got it! Thanks