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 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, 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 which 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, 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		-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	+when pushing code to the code repository there should be DevOps infrastructure that triggers a CI pipeline executing all tests. Doing that enables you to get your code comprehensively tested while you can directly go on working without the need to wait. If the CI pipeline succeeds, the test suite proofed your code to be fine. If the CI pipeline fails, you should get a notification like an SMS or Email which triggers a ringing tone, so that you abort your current work immediately to fix the problem. Push the fix again and continue working without waiting for any tests to finish.
28	28
29		-It is not uncommon that one developer triggers many CI pipelines running simultaneously for the same developer. While this may require advanced DevOps infrastructure, it's often worth the investment. Or you can simply use cloud providers that do this automatically in the background.
	29	+It is not unusual that many CI pipelines run at the same time for the same developer. Although this may pose an advanced DevOps infrastructure it is often worth the investment. Or you simply use cloud providers automatically taking care of that in the background.