Skip to Content

Changes for page Test Speedup

Last modified by chrisby on 2025/03/08 11:39
From version 1.29
edited by chrisby
on 2024/05/05 17:38
Change comment: There is no comment for this version
To version 1.24
edited by chrisby
on 2024/05/05 17:33
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -18,12 +18,12 @@
18 18  
19 19  ### Asynchronous Testing
20 20  
21 -**Synchronous Testing**
21 +The Problem
22 22  
23 -A simple test-driven workflow is to write new code, execute tests locally, wait for them to finish and if they pass then going on. To avoid long waiting times being unproductive, you only execute a few, very fast tests sacrificing that all tests check your latest changes. This is tolerable when working on an isolated concerns working with unit tests e
23 +A simple test-driven workflow is to write new code, execute tests locally, wait for them to finish and if they pass then going on.
24 24  
25 -**Asynchronous Testing**
25 +The Solution
26 26  
27 -is a workflow that works well when the test take a few seconds only. This has the disadvantage that you only check your code changes for correctness against just a few very fast tests.
27 +is a workflow that works well when the test take a few seconds only. This has the disadvantage that you only check your code changes for correctness against just a few very fast tests.
28 28  
29 -Instead of waiting for your tests to finish locally, you should have a DevOps infrastructure which triggers a CI pipeline when pushing the code executing all tests. Doing that enables you to directly go on working without the need to wait minutes for the tests to finish. 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.
29 +Instead of waiting for your tests to finish locally, you should have a DevOps infrastructure which triggers a CI pipeline when pushing the code executing all tests. Doing that enables you to directly go on working without the need to wait minutes for the tests to finish. In case the CI piepline 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.