How Test-Driven Development can help you avoid bugs

In Plain English HQ is a hub for explanations of complex topics, offering articles, guides, and tutorials across various domains. By distilling intricate concepts into easily understandable language, In Plain English HQ facilitates learning and comprehension for readers seeking to grasp challenging subjects without unnecessary jargon or confusion.

Python in Plain English

Test-Driven Development is the process of developing a program only after having some tests written down. The main idea is to develop each new feature separately, one at a time. Here are the main advantages (and disadvantages) of using Test Driven Development. Using TDD may not be the best choice if you do not have a lot of time.

How to Write Programs Without Bugs

Basic overview of TDD. Title is a little click bait-y, but basic into to TDD is decent.

The code side:
<ol>
<li>Lint</li>
<li>TDD</li>
<li>Less code</li>
<li><a href="https://en.wikipedia.org/wiki/SOLID" target="_blank" rel="noopener nofollow">SOLID</a></li>
<li><a href="https://en.wikipedia.org/wiki/KISS_principle" target="_blank" rel="noopener nofollow">KISS principle</a></li>
<li><a href="https://en.wikipedia.org/wiki/Multitier_architecture" target="_blank" rel="noopener nofollow">Multitier architecture</a></li>
<li><a href="https://en.wikipedia.org/wiki/Software_design_pattern" target="_blank" rel="noopener nofollow">Software design pattern</a></li>
<li>Static type system - avoid some bugs in compiler time</li>
<li>Use well-tested third-party packages, don’t create on own.</li>
</ol>
Clean code, refactor, SRP etc…
The tool side:
<ol>
<li>Code Quality and Code Security - sonarqube</li>
<li>Preprocessor and postprocessor</li>
<li>Code generator - Generate code by tool, not by hand</li>
<li><a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity" target="_blank" rel="noopener nofollow">Cyclomatic complexity</a></li>
<li>APM and error tracing.</li>
<li>Code format</li>
<li>Intellisense</li>
<li>AI pair programmer - <a href="https://copilot.github.com/" target="_blank" rel="noopener nofollow">copilot</a></li>
</ol>
etc…

try {
…
} catch () {
<a href="http://console.info" target="_blank" rel="noopener nofollow">console.info</a>(“this is not a bug, this is a feature :)”)
}

Very useful amount of knowledge I got from this post that encouraged me to start learning TDD principle

I have experience with TDD and it can be really helpful when team is facing an issue where tickets are often QA failed because of some bugs. In this case with TDD you are not loosing time for switching contexts - when ticket is QA failed you’ll probably need to revisit it again and find the source of the problem and after it you need to get back to the task you have been already working on. And switching context can be really time consuming