Today: • Finished the PR with removing much of JS stuff. • Continued researching the new and the old testing infrastructures. It seems the main problem of the old one is that it's based on the old JUnit API heavily, for example there are some methods that should be called before and after each test, and they are hidden deep inside the superclasses of our test class. The main problem of the new one is that it uses a specific organization of code that we need to follow (facades, handlers and so on: https://github.com/JetBrains/kotlin/blob/master/compiler/test-infrastructure/ReadMe.md), and I still don't understand it well. We will definitely have to write some code there. Our main task in testing is to start using JUnit5 that will allow running separate test cases in parallel, thus speeding things up. For now, our testing can run only different test classes in parallel, and it's less effective compared to per-case parallelism possible with JUnit5. It can be reasonable to firstly try to get rid of the old JUnit API in our tests, but just invoke the same code manually. I guess this way we could just use JUnit5 per-case parallelism not writing much new code. Or I could continue with switching to the new testing infrastructure with its entirely new DSL right away. This will require more research and rewriting the most of our testing code to that specific organization of code. I'm not sure which way is faster, probably the first one, but both should give the same result that we need: tests should work much faster since true parallelism will be used. In case of any ideas please share 🙂 Next time: • Choose the initial way of switching to JUnit5 and continue with it.

Thanks, approved and merged! Just to be sure, is there any specific reason to focus on the new test infra? Is the old one getting unsupported soon or sth?

Well, I've mentioned this a bit above in this channel:

A random idea about speeding up tests: I've noticed that when tests are

starting, all the cores are loaded at 100%, but after some time less and

less cores are loaded (see the screenshot). And at the end, only about 1

core or 2 cores are working.

If we make all cores work during the whole testing, I guess the tests will take less time

had a call with @ dmitriy.novozhilov (sorry for pinging) – he suggested to switch to new testing infrastructure that utilizes JUnit 5 and makes parallel tests launching more effective. Some work will be required but I think it's needed for us and also the old testing infrastructure is going to be deprecated.

Do you see some speedup with the new infra? CI doesn't show it, as far as I see

The PR you've merged doesn't contain any changes regarding infra, only getting rid of JS stuff and refactoring. Also, remembering that GH Agents don't have much CPU cores, I guess switching to the new infra won't be much noticeable on CI.

is there any specific reason to focus on the new test infra? Is the old one getting unsupported soon or sth?

However, our machines (mine and yours) have many cores and for us the new infra should speed things up as more cores will be used during the testing. Also, as dmitriy.novozhilov said, the current testing infra is going to be removed after JS and Native switch to the new one.