Less Hard-coding
We are always tempted to hardcode
things. It make our life easy. But this can make maintaining that
code a big issue. I had to change some of the places that I did
hardcode due to different reasons.
Dates and times
When working with date and times you
might forget that, those things are changing. I did this mistake ones
in the testing. I was asked to test the service locking
functionality. We can lock a service for a specific time. I just
hard-corded the dates and times and did the testing. Soon I realized
that, if we are going to use them in the future, test going to fail.
You might think that is foolish from me, but believe me we miss those
little things while cording.
Use of Constants
If you really need to hardcode
something do it through a constant, at the bigging of the code. So if
it get changed, it is easy for someone else to find and change it
Do not leave thing behind
When you create any objects for testing
and if you have done any configuration changes to the product for
testing, make sure you undone them before you leave. Those objects
and changes can break other tests by other users. You can use
@AfterClass for that purpose.
Avoid Test anti-patterns
Just search for the test anti-patterns
and you will find lot of them that you should avoid, or at least try
to avoid.
Coverage Vs Stable Product
When we are testing, we normally get
blinded by the coverage. But always our goal should be to build a
stable product. No matter what is the test coverage if our product is
failing, all the hard work is for nothing. This is told to me by our
team lead Krishantha ayya.
Good Articles
