Skip to Content

Changes for page Test Speedup

Last modified by chrisby on 2025/03/08 11:39
From version 1.36
edited by chrisby
on 2024/05/05 17:46
Change comment: There is no comment for this version
To version 1.46
edited by chrisby
on 2024/05/05 17:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -20,8 +20,10 @@
20 20  
21 21  **Synchronous Testing**
22 22  
23 -A simple TDD workflow is to write new code, run tests locally, wait for them to finish, and if they pass, move on. To avoid long wait times, you run only a few very fast tests. This is tolerable when you are working on isolated code and using unit tests, but as soon as integration of the new code with the old code comes into play, it becomes a problem. You have two bad choices: either you run only a few fast tests and do not use the full power of your test suite, possibly missing bugs that would be easier to fix if they were caught earlier, or you run all the tests locally and are unproductive for a long time while waiting for them to finish. This problem can be solved with asynchronous testing.
23 +A simple TDD workflow is to write new code, run tests locally, wait for them to finish, and if they pass, move on. To avoid long wait times, you run only a few very fast tests. This is fine when you are working on isolated code that is checked by unit tests, but as soon as integration of the new code with the old code comes into play, it becomes a problem. Now you have two bad choices: either you run only a few fast tests and do not use the full power of your test suite having a low coverage, possibly missing bugs that would be easier to fix if they were caught earlier, or you run all the tests locally and are unproductive for a long time while waiting for them to finish. This problem can be solved with asynchronous testing.
24 24  
25 25  **Asynchronous Testing**
26 26  
27 -You should have DevOps infrastructure which when pushing code to the code repository triggers a CI pipeline executing all tests. Doing that enables you to directly go on working without the need to wait minutes for the tests to finish. If the CI pipeline succeeds, In case the CI pipeline fails, you should get a notification to fix the CI pipeline immediately. This enables quite comprehensive testing, even having the same testing jobs running in parallel, even long taking ones.
27 +When you push code into the code repository, there should be a DevOps infrastructure that triggers a CI pipeline that runs all the tests. This allows your code to be comprehensively tested while you continue working without waiting. If the CI pipeline succeeds, the test suite has proven that your code is good. If the CI pipeline fails, you should get a notification like an SMS, email chat that triggers a ringing tone or desktop notification so that you immediately stop what you are doing to fix the problem. Push the fix again and continue working without waiting for the tests to finish.
28 +
29 +It is not uncommon to have many CI pipelines running at the same time for the same developer. While this may require an advanced DevOps infrastructure, it is often worth the investment. Or you can simply use cloud providers that do this automatically in the background.