Philosophy of Testing
The field of automated software testing is a mixture of art and science, with a side of alchemy. Different folks have different needs that they want satisfied and hence, they approach testing very differently. In the end, people do what works for them, and no single methodology works for everybody, which makes the field of testing a smorgasborg of techniques.
The more important code is to your business or lifestyle, the more important writing tests and running tests becomes.
What is Test Driven Enlightenment?
Tests First, or Code First?
There are many people in the testing world that say all your hair will fall out and you will die alone if you don't write your tests *first* and then add the code later. They like to use terms like "Test Driven Development" or "Behavior Driven Development" to describe this philosophy.
There is nothing wrong with this philosophy, but experience has taught me that hard and fast rules rarely hold up to the test of the real world. Like many things, some kind of "Pareto Principle" is applicable, i.e. 80% of the time, you should probably write tests first, but around 20% of the time, it may make more sense to let the code flow first. Letting the code flow first is sometimes beneficial at the very beginning of a project, where the coder is starting from a blank slate.
Although it is possible to write tests as the absolutely first thing, sometimes having a tiny bit of structure first helps really helps.
Kinds of Tests
Many people start to get confused when people speak of integration tests, unit tests, acceptance tests and many other flavors of tests. One should not worry too much about these terms. The more tests you write, the more nuances you will see and the differences between tests will become more apparent. Everyone does not have the same definition for what these tests are, but the terms are still useful to describe kinds of tests.
Unit Tests vs. Integration Tests
Unit tests and integration tests form a spectrum. Unit tests test small bits of code, and integration tests verify how more than one unit fits together. The test writer gets to decide what comprises a unit, but most often it is at the level of a function or method, although some languages call those things by different names.
Hey! The above document had some coding errors, which are explained below:
- Around line 1:
Unknown directive: =head0
- Around line 3:
A non-empty Z<>