Testing Tiers

Testing seems to be a major focus on every dev team. How are we testing? What are we testing? Whats our test framework? Do we have dedicated QA? I would say there is no standard but many different standards. Here is a very general take on a testing structure to an application. You should be able to apply this organization to any framework. The reason I titled this article Testing Tiers is because I believe the best approach to test is a set of layers that reinforces other tests. This layering is an extra check on application of your logic. Not only do you have the ability to do X but you are doing it at the right time and in a robust way.

Unit

You should have a group of "unit tests". These are test to ensure that the logic you have that has no state works correctly. This is your typical formatters, validators, calculations. You should be able to load your application and test inputs and out puts via command line without any other services. Mocks shouldn't be required.

Feature / Integration

Feature level test are tests that require a persistence check. Usually a feature will have many different persistence checks. For example if I have a shopping cart feature I probably have functions to store an item, get an item or a list of items , and delete an item. These each require persistence checks and should be testable separately. You'll need to mock or have a storage engine to ensure your application code has a standard for holding and retrieving state. I suggest running a full local version of your storage engine, as these are prone to have version anomalies especially for some unique data formats. In general try to have your test environment as close to the production version as possible.

Behavioral

Behavioral test are more than just a list of feature tests in a particular sequence. Each behavior is a story of what a user is trying to do. This is an important concept as an approach to building and understanding your tests. Its a way to give the test meaning. As you discover bugs in your code you can ask. How did this happen? The answer is a user story or a behavior that is testable. With behavioral testing are answering different version of the question; Did you call the right method, on the right feature, in the right order, while passing it the correct data?

If you have a process for these 3 levels of testing you should be able to determine at any level where a bug might occur. Is it a missed calculation in a function, a misspelled object key in save method of a feature, or is it the handing off of data from one feature to another. Bugs will always occur so make sure you have an understanding on how organize them and to make sure the same one does not happen again.