Once upon a time there was a Q&A that happened as follows…
Q:So when can you say that your local dev environment is ready?
A:When you have run a comprehensive unit test, pre-existing or drafted yourself.
Q:What is a comprehensive unit test?
A:One that covers all major components of the architecture you are working on.
Q:What can be the major components of an architecture, one may be working on?
A:Layer Code, deployment, DB, Jndi context, orm context, 3rd party API context.
Q:What’s your point?
A:You environment ain’t ready until all your environments are not accessible from your box. The best way to ensure this is with a unit test and know thy environment!
Writing unit tests for working on a piece of code is an exciting task that I enjoy.
To accomplish this with ease, for now my junit arsenal has the following approach:
1/ Mathematical Induction
2/ Boundary Value Analysis
3/ Permutation of the variables.
Care to share?
Today while working at my desk, I came across a situation where a colleague was writing some piece of code as a missing implementation when a module changed hands.
There was little time and so, the part had to be just written for the sake of it.
And that’s where I wanted to dis-associate myself from the partnership.
It so happened that the situation was getting complex and two heads were good at solving it.
I could not yet overcome my hesitation to help in a piece of code that would not be tested, so rather than saying this, I called it the white code: The one that was written on the white background of eclipse editor and never get through living in the main memory and get executed!
To my happy surprise, he got motivated and understood my hesitation and ensuring the missing implementation code was atleast working on a non matching scenario and breathe life into the code.
There we called it the green code:Simply because it was executed, not for complete scenarios, but it was executed!
Green is the way to go!
Came across an interesting scenario.
Had a pre-running test case. And then removed the @Test annotation from it, and voila!
It seems JUnit developers really thought of this scenario where a developer un-annotates a test method and they gave an appropriate exception!
Well this seems to be an eclipse bug.It occured when I copied a window eclipse shared project and tried to run it.
I could not overcome this error till date, using following resolutions:
1/ Exclude junit3.3(NA)
2/Remove extension from TestCase.(NA)
3/Remove duplicate junit jar from the project.(NA)