Changes for page Test Speedup

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,8 +1,7 @@
1	1	Fast testing not only saves time, but also enables more frequent execution, leading to improved code quality. Optimizing the speed of test execution is therefore critical. While extensive and frequent testing is ideal, it shouldn't excessively slow the pace of development.
2	2
3		-### Measures
	3	+### General Measures
4	4
5		-* **Test type segregation**: Unit tests tend to run much faster than other types of tests. For large test suites, you should consider running unit tests regularly on the developer's local machine, while scheduling more resource-intensive tests in a CI environment. The CI environment can, for example, run the slower tests in parallel and notify you just in case something fails. If the tests take too long for this approach, you can run them at a fixed rate, usually once a day at midnight. Also see [[Types of Tests|doc:Software Engineering.Testing.Types of Tests.WebHome]].
6	6	* **Selective Testing**: You don't need to run all tests every time. It can be sufficient to run only the tests related to recently changed code, or only the fast tests, and then run all the tests when you finished a major implementation step.
7	7	* **Mock slow dependencies** to minimize code execution time, especially operations such as I/O, transaction management, and networking.
8	8	* **Prefer in-memory databases during testing** for cleaner and faster operations compared to standard databases.
...	...	@@ -10,20 +10,16 @@
10	10	* If execution time remains constant, CPU is the bottleneck. Mitigate with faster CPUs, more cores, or additional machines.
11	11	* If execution time decreases, I/O is the bottleneck. Use more threads, faster storage (such as SSDs), or additional storage for concurrent filesystem operations.
12	12	* **Improve I/O speed by using RAM disks**, such as Linux's tmpfs tool. Configure your tests to direct all file interactions to the RAM disk.
13		-* **Parallelize test execution.** Multiple threads can improve execution speed even on single-core processors by keeping the CPU busy while other threads wait for disk I/O.
14		-* **Offload CPU-intensive tasks** to cloud-based computing resources using automation scripts:
15		- * Upload project files to the cloud.
16		- * The cloud service builds the project, runs tests, and generates a test report.
17		- * Upon completion, download the test report from the cloud.
	12	+* **Parallelize test execution.** Multiple threads can improve execution speed even on single-core processors by keeping the CPU busy while other threads wait for disk
18	18
19		-### Asynchronous Testing
	14	+### Using DevOps Infrastructure
20	20
21		-**Synchronous Testing**
	16	+A good developer should learn modern DevOps concepts, especially CI pipelines/jobs (in GitLab terms). Beginners may want to start with a third-party DevOps infrastructure provider, such as GitLab or GitHub.
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 waiting 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, this becomes a problem. You have two bad choices of Either you run only unit tests and do not take advantage of the full power of your test suite, or you run all tests and are unproductive for a long time while waiting for them to finish. This problem can be solved with asynchronous testing.
24		-
25		-**Asynchronous Testing**
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.
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.
	18	+* **Test type segregation**: You should consider regularly running fast tests, such as unit tests, on the developer's local machine, while scheduling more resource-intensive tests in a CI environment.
	19	+* **Asynchronous Testing**: Running the entire test suite locally results in long wait times that block development. In such cases, you simply push the code to the source repository and have a CI environment that runs the test suite while you continue development immediately. If a CI job fails, you are notified so you can stop development and fix the problem first.
	20	+ * **CI Concurrency** can drastically enhance test execution speed.
	21	+ * **Enable concurrent CI pipelines**: The developer should be able to push code and spawn new CI pipelines that run immediately on different machines while old pipelines may still be running.
	22	+ * **Enable concurrent CI jobs**: Split the test suite into multiple independently executable CI jobs to allow concurrently execution.
	23	+ * Both of these measures require multiple machines to run the jobs, which is quite demanding on the DevOps infrastructure, but often worth the cost.
	24	+ * **Scheduled Testing**: A less resource-intensive alternative to the above approach is to run large test suites at a fixed rate, typically once a day at midnight, which is less demanding on the DevOps infrastructure.