Testing is a really important part of coding that is very often ignored by developers. How many times have we all experienced that pushing code to production (or not even reaching that far) had broken part our service / website?
It especially sucks when a part of the system that is totally unrelated to our code ends up having a problem due to our changes. That phenomenon is usually referred to as a side effect. Putting together several chunks of code that were written by multiple developers is a recipe for disaster as a result of side effects.
Conflicts may arise in files that were modified by more than one person. These conflicts often end up causing bugs and other unpleasant system behaviour. So what do we do to put ourselves in a better place?
You might have heard this term by quality engineers (brrr who even talks to them? 😆) when they want to describe how testing can be abstracted in multiple levels. In a world where releasing doesn’t result in us being in a cold sweat, we need to make use of the testing pyramid (along with a “few” other concepts). That way, we will feel more confident that our new code is not going to break the system that easily.
Image by oreilly.com
As shown in the image above, the testing pyramid includes 3 stages.
While at Google they like to refer to each one of them based on the impact it has on the system (thus the size), I think the rest of the world prefers the technical term when referring to each one of them.
