In professional software development there is a methodology called «Test Driven Development» (TDD). It has been around for more than 20 years, but since it has been taught at universities and lived in the industry, its popularity has grown steadily. TDD consists of three phases:
Red: First, the programmer writes an automatically executable test case. This should not yet be successfully executable (red). Let's call this step specification.
Green: The above test case can now be fulfilled by writing the code to be tested. The feature or a part of it will be implemented and the test case will be green. Let's call this step verification.
Refactoring: In the third phase, you look at the written program code again and methodically check whether you could do something even better (more stable, safer, faster). This step is called refactoring and is important for future development speed.
The above three phases run very fast in practice. A cycle lasts about 30 seconds.Although TDD is regarded as state-of-the-art, the discussion is far from over. A continuing education course discussed what influence TDD can have on the architecture of a software project. I refer to this discourse and explain my theory about what happens when junior developers are not responsibly supported: https://medium.com/@schmijos/test-induced-design-damage-3bc30ed5bc7c
