Changes for page Test Speedup

Summary

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

Details

Page properties

Content

...	...	@@ -20,10 +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 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 a few fast tests and do not use the full power of your test suite, resulting in low coverage and possibly missing detecting bugs that would have been easier to fix if they had been 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, 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 yet isolated code and working with unit tests but as soon as integration with the rest of the code comes into play this becomes a problem. Either you execute only unit tests not taking advantage of the whole mightiness of your test suite or you run all tests and be unpro
24	24
25	25	**Asynchronous Testing**
26	26
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 extensively tested while you continue to work without waiting. If the CI pipeline succeeds, the test suite has proven that your code changes are okay. If the CI pipeline fails, you should receive a notification, such as an SMS, email, or chat message that triggers a ringtone, or a desktop notification, so you can immediately stop what you are working on and fix the problem first. Apply the fix and continue working without waiting for the tests to finish.
	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		-It is not uncommon for a single developer to trigger many CI pipelines running simultaneously. While this technique may require advanced DevOps infrastructure to implement, it's often worth the investment to set it up. Or you can simply pay cloud providers like GitLab or GitHub to use their infrastructure, which provides this capability.
	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.