Changes for page Test Speedup
Last modified by chrisby on 2025/03/08 11:39
Summary
-
Page properties (4 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -Test Speed up1 +Enhance Test Execution Speed - Parent
-
... ... @@ -1,1 +1,1 @@ 1 -Software Engineering.Testing.WebHome1 +Software Architecture.Testing.WebHome - Syntax
-
... ... @@ -1,1 +1,1 @@ 1 - Markdown1.21 +XWiki 2.1 - Content
-
... ... @@ -1,18 +1,19 @@ 1 -Fast testingnotonlysaves time,butalsoenablesmore frequentexecution, leading to improved code quality.Optimizing thespeed of test execution is thereforecritical.Whileextensiveand frequenttestingisideal,itshouldn'texcessively slowthe pace of development.1 +Fast-executing tests require less time and are executed more frequently, contributing to improved code quality. Therefore a high test execution speed is important. 2 2 3 -### 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 -* **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. 4 +=== Measures === 5 + 6 +* **General code optimizations** such as faster algorithms, data types, etc. 7 +* **Test type segregation**: Unit tests typically run much faster than other types of tests. For large test suites, consider running unit tests regularly on the developer's local machine, while scheduling more resource-intensive tests to run at a fixed rate in a continuous integration environment, for example. 8 +* **Partial testing**: You don't have to run all tests every time. Often, it is sufficient to run only the tests related to recently changed code. 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. 9 9 * **Identify performance bottlenecks** by increasing the number of threads: 10 - 11 - storage(such as SSDs), or additional storagefor concurrent filesystem operations.12 +** If execution time remains constant, CPU is the bottleneck. Mitigate with faster CPUs, more cores, or additional machines. 13 +** If execution time decreases, I/O is the bottleneck. Use more threads, faster memory (such as SSDs), or additional storage. 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 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. 18 -* **Developer Branches**: 16 +* **Offload CPU-intensive tasks** to cloud-based computing resources: 17 +** Upload project files to the cloud. 18 +** The cloud service builds the project, runs tests, and generates a test report. 19 +** Upon completion, download the test report from the cloud.