Changes for page Test Speedup
Last modified by chrisby on 2025/03/08 11:39
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -20,10 +20,12 @@ 20 20 21 21 **Synchronous Testing** 22 22 23 -A simple TDDworkflow is to write new code,runtests locally, wait for them to finish,and if they pass,move on. To avoid long wait times, yourunonlya few very fast tests. This is fine when you are working on isolatedcode that is checked byunittests,butassoon as integration ofthenewcode with the old code comes into play,it becomes a problem. Now you havetwo bad choices: eitherourun afew fast testsand do not use the full powerofyour test suite, resulting in lowcoverage and possibly missingbugsthatwould have been easier to fix if they had been caught earlier, or you run allthetestslocally and areunproductiveforalong time while waiting for themtofinish. This problemcan be solved withsynchronous testing.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 wYou only execute a few, very fast tests sacrificing that all tests check your latest changes. 24 24 25 +Although asynchronous testing has its place when 26 + 25 25 **Asynchronous Testing** 26 26 27 - When you pushcodeintothe coderepository,there should beaDevOps infrastructurethat triggersa CI pipelinethat runsallthe tests.Thisallowsyourcodetobe extensivelytested whileyou continue to work without waiting.IftheCI pipelinesucceeds,the testsuitehas proventhatyour code changesare okay. Ifthe CI pipeline fails, youshouldreceive a notification, such as an SMS,email, or chat messagethat triggersaring tone, or a desktopnotification, so youcan immediatelystopwhatyou are doing andfix theproblem.Push thefixagain and continueworking without waiting for theteststo finish.29 +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 isnotuncommonto havemanyCI pipelinesrunning simultaneouslyfor thesamedeveloper.While thismayrequireadvancedDevOpsinfrastructure,it'softenworththe investment.Oryou cansimplyuse cloudproviders thatdothisautomaticallyinthebackground.31 +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.