Optimize tests

[JanCizmar]

• Prevent truncating db between each test
  • I have already started with this in this PR chore: Don't truncate database tables between tests #2572, please continue with rest of the tests
  • If it's not possible to simply make the data unique, please just add the @CleanDbBeforeMethod annotation and dont't waste much time with that
  • Run tests in profiler and search for scheduled operations running in separate thread and prevent this in tests and enable it only for tests where such behaviour is required
  • You can find these by searching for "@scheduled"
  • Join fast suites "data:test", "ee:test", "security:test" to single run, so we don't have to start it in multiple VMs as we do now.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[JanCizmar]

Sorry, for not being clear. I meant separate/parallel jobs in GitHub workflows. (We called these VMs in my previous job)

[laz-001]

Split 2 new issues out, in the end you'll have 3 issues.

Issue 1

(change the title of the current issue, add a bounty, this is a clearly isolated onw issue)

Prevent truncating db between each test

I have already started with this in this PR #2572, please continue with rest of the tests
If it's not possible to simply make the data unique, please just add the @CleanDbBeforeMethod annotation and dont't waste much time with that

Issue 2

(create a new one for this)

Run tests in profiler and search for scheduled operations running in separate thread and prevent this in tests and enable it only for tests where such behaviour is required
You can find these by searching for "@scheduled"

Issue 3

(this one seems trivial, tried a day, ended up yelling at gradle. Nice isolated issue if a dev wants to play a bit with gradle/ci. Could be solvable via a trivial matrix setup)

Join fast suites "data:test", "ee:test", "security:test" to single run, so we don't have to start it in multiple VMs as we do now.

---

You COULD add bounties to the simpler issues, though sometimes it just creates workload for you.

[laz-001]

Then, we have:

• gradlew test optimization (done so far)
• single-test optimization, emphasize on test-change-iteration (e.g. when writing tests)
• single-test optimization, emphasize of code-change (normal app development)
• ci optimization

Those are really different issues, and one can affect the other positive or negative.

My suggestion is simple:

• you pay for the gradlew test optimization and the other work so far
• I give you the first results for single-test (30% less execution time on my machine for a single test, when the CODE was changed)
  • if you pay for this part, I go on with the next step.

I have solved the problem (theoretical work, cutting test-times to half), the implementation could take 2 weeks. It is NOT in context of a $3K bounty, and I'm not sure how we make it with the payments, because I simply can't take drama when working on such difficult tasks.

In any case, you need to accept that I provided results and compensate me for it, otherwise I can't continue.

[laz-001]

• follow-up: [TESTS] Reduce db-Cleanup Time #3127

[laz-001]

@JanCizmar , take a look at the email i sent you, we should go on with all this stuff.