Example Based Testing

Almost every engineer writes example-based tests. You pick some inputs, determine what the output should be, and then write some sort of test harness that will provide those inputs to the code under test and check that the output matches your expectations. It’s the first kind of testing most of us learn and it makes up the bulk of nearly every test suite I’ve ever worked in. It’s so familiar that it has become more or less invisible, in many cases when we talk about tests, we are implicitly assuming that we’re talking about example-based tests, and rarely do we actually stop to reflect on what it is (and isn’t) doing for us as a testing methodology.

Test Levels

I’m planning on starting a series of blog posts discussing different testing methodologies, but before I do that, I need to get a rant off my chest, and it pertains to a topic that is discussed ad nauseum whenever you bring up “testing methodologies.” A topic that is, in my mind, neither very interesting nor very valuable and gets in the way of more useful discussions. The pointless conversation we keep having Have you ever been in a meeting and someone starts discussing the relative importance of unit, integration, etc.