A team I am doing work for has two versions of bpmns. Each to support interacting with the same product, but different version of that product.
They test both versions of the bpmns in the same Spring Junit execution series, but under different source files. The problem I found is that the bpmns are the same name (KEY_) for each test. But, they do have some very slight differences in the file itself.
If test A goes first, camunda loads A bpmns into the Spring database. When test B goes, camunda loads THOSE bpmns, of the same name, into the database but because the KEY_ matches, it creates it with a higher version number.
The problem comes if we have another test that then wants to use A bpmns. The query camunda uses looks for the latest version, which in this case is now B. Which conflicts with the test.
The previous devs thought that the TestPropertySource that selected the B bpmns were what was being used by camunda. Unbeknownst to them, camnunda was selecting the latest inserted bpmns. They got by with this before because the order that the UT’s were executing. The order just changed. And now… those bpmns are not being used where/when expected.
I tried looking into how to reset that database in between tests, but the few sources I found didn’t end up working out. I have a fix that makes this race condition work, but it doesn’t fix the race condtion I face.
Can anyone recommend how to reset/reload that internal database?