Imagine how Test Driven Development helps you.

I decided to write this article to be able to provide a general understanding about test driven development and how it may help you. When I am talking about the subject I will refer to bugs as real world bugs like a single fly or a mosquito etc. and Testing approaches as weapons used to kill them ie. smashing, electrical killers or an axe (well can you kill a mosquito with an axe, theoretically yes you can; yet we will see the results ;)) I will number these testing approaches from 1 to 3 and finally return back to the real world mosquito scenario.

1-) Unit Testing with Mock APIs: (SMASH)

Lets start with unit testing and mock APIs around them. When we need to talk about unit testing keep in mind there other concepts such as Fake APIs as well. Well to give you an understanding about the difference of these 2 approaches:

a-) For Mock API you can use mock frameworks such as (Mockito for Java Google Mock for C++) and all you will have to do is write the behavior of your mocked API during your Unit Test cases as pre-compiled expectations and you will spend no or minimum (minimum for Adapting API implementations) effort on implementing the mocked api. Because mock framework does the implementation for you, or better to say; mock framework provides you an API as if there is a real API interacting with your unit or module under development.

b-) Fake API approach is much more time consuming approach for a developer. Because based on your real API you have to implement a "Fake API" which behaves like your real API and you will have to provide switch like structures to manipulate the behavior of the implemented fake api.

Well considering from development point of view; mock approach seems much more reasonable compared to the fake approach. But you have to be careful about the design of your software module if you follow the mock approach. The mock approach requires you to provide a visibility for 3rd party APIs from out of your implemented module. Here the Dependency Injection is the remedy for such design considerations which I will discuss about on another article.


Pros:
- Isolation of development modules completely from each other during design.
- Unit tests for a module run in seconds or mseconds.
- You can find simple bugs early in the development cycle.
- Maintenance and refactoring efforts of the software module is significantly reduced.
- The developer is more confident about his software modules.
- You do not need a test bed.
- The unit tests can be %100 percent automated.

Cons:
- Development effort of software developer may have been doubled during the initial development. (considering reduction of maintenance efforts in later cycles this negative affect is balanced in whole life cycle of the software module).
- Another designing requirement of the software module rises such as "Design From Test Point Of View".


2-) Integration Testing:(ELECTRICAL BURNER FOR KILLING INSECTS)

Now that each software module has been developed in an isolated kind of approach, it is time to bring them together or all together and see the affects of them on each other. There are some commercially available tools beside home made integration test frameworks which software developers can use for such purposes. You can think of this stage as replacing the mock apis (during unit tests) with real implemented modules by other developers. Generally an integrator such as the technical leader of the project drives this effort. I have an important suggestion here: INTEGRATE OFTEN such as once an every week or every two weeks. Because other wise it will be hard to keep in line regarding the major changes during development.

Pros:
- Gives you the ability to trace undesired affects of the integrated modules on each other, before releasing an alpha version of your product.
- Good approach for locating hard to find bugs.
- Confirms that specifications and protocols are doing fine in coordination.

Cons:
- Takes more time than a unit testing such as minutes or more depending on your environment
- Requires you to provide a real test bed with real software and hardware units.
- Harder to automate compared to Unit Tests because there may be many dependencies from outer world such as (Dbs, Network conditions etc....)


3-) Black Box Testing: (AXE)

This is actually a very large topic including sub headers such as Regression, Functional, Stress etc. tests . So from a developer point of view this effort is driven by other people, tools or organizations such as Manual and/or Automated Test Engineers, 3rd party testing organizations, Black Box Automated Test Tools etc. So I will leave you the googling part and just mention about main Pros and Cons.

Pros:
- Overall software product is tested by professional testers in alpha and/or beta cycles before releasing the product to the market.
- In this cycle inconsistencies are diminished from a user point of view.

Cons:
- You really need a good test bed, test setup, automated test environment for black box testing.
- Takes days or even months to test the overall product.

KILLING THE MOSQUITO SCENARIO

- You use the AXE to smash the mosquito after many tries you are very tired, the walls are ruined and the mosquito is still alive and kicking.
- Than you decide to use the ELECTRICAL BURNER, you wait for the sun to settle down and the room is dark you plugin the device and wait for the mosquito, but the mosquito found another light source and made his way along that direction and he never hit the electrical burner. You are very tired and sleepless, the mosquito is still alive and buzzy.
- Than next morning you decide to smash the mosquito on the wall, you are very tired so after many attempts you finally managed to get a bloody spot on the wall.

That mosquito was a NULL POINTER that some how was never hit during your Integration or Black Box tests.


Have a nice day;

Baris ERGUN.