beezwax blog

There are entire books written on testing. And it surely feels more an art than a science. My approach is similar to Kent Beck’s:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.

https://stackoverflow.com/a/153565/1015566

He goes on to add that different people will have different strategies and, at the end of the day, you just have to do what works best for you and your team. Extremely practical, and the approach I personally follow.

This won’t be a detailed post on every possible topic on tests and testing in Object-oriented Programming (OOP). There are many books about that already. Instead, this article will cover the basics of testing, so you understand how and why we test, and you can adapt it to your own needs.