Home     RSSRSS

Posts Tagged ‘Unit Testing’

Unit Tests Test Case – Is My Code Output Correct

November 20, 2013 by kiranbadi1991 | Comments Off on Unit Tests Test Case – Is My Code Output Correct | Filed in Development, Others, Testing

One of the goals for writing unit tests is to ensure that code does what it is supposed to do. When we write and compile the code, we know it gets through perfectly without any errors. However not having any errors do not necessarily mean that it does what it’s supposed to do. We need to have some mechanism to know that the code produces the results we require and we also have other means to validate the code output. Your test case for Unit test should test for results or code output validity.

Consider the below simple program add 2 numbers (I know this example is too easy and not practical one ,however this is best example coming to my mind now while writing this post,sorry I do have some great unit tests for my piece of code, I will share those as well later on)

public class AddTwoNumbers {

public double add (double number1, double number2) {

Return number1 + number2;



The Intended purpose of AddTwoNumbers is to take 2 double values and do the addition. We need some mechanism to know that when this program gets executed we are indeed doing addition and program is also not giving us back any runtime exception. Probably we can write the test for this program something like below,

public class AddTwoNumbersTest {

public static void main(String[] args) {

AddTwoNumbers addtwonum = new AddTwoNumbers();

double output = addtwonum.add(40,50);

if (output != 90) {

System.out.println("Bad result: " + result);




One of the other ways to test this program is with Junit and use its assertEquals Method.

import static org.junit.Assert.assertEquals;

import org.junit.Test;

public class AddTwoNumbersTest {


public void testAddTwoNumbers() {

AddTwoNumbers addtwonum = new AddTwoNumbers();

double output = addtwonum.add(40,50);

assertEquals(60, result, 0);



Junit probably is one of the best library for unit testing the java code. Probably sometimes later I will write more on Junit. In case while writing the code ,the requirements are not clear, then probably making some assumptions surely helps. However we need to ensure that our assumptions are repeatedly clarified with users or relevant stakeholders.

So the first unit test case for your piece of code should be to verify that your code does what it is supposed to do.


Tags: , , , ,

Unit Testing–What to Test

October 9, 2013 by kiranbadi1991 | Comments Off on Unit Testing–What to Test | Filed in Development, Others, Quality, Testing

One of the frequent discussions I often get into with developers especially in agile projects is how to write the test case for the class or method and what should we be testing in the unit tests.

There seems to be difference in opinion among folks as what unit test case needs to cover? Or what should we be testing with unit tests?

Should we write the test for both positive and negative input values or should we write the test that shows the code is just enough working? Or should we write the test case for all the possibilities that the code is going to fail or it’s going to be used?

All of these questions seems to be perfectly valid and there isn’t a single right answers to it. However based on my experience and little bit of wisdom, I can say that if you are working with experienced veteran programmer, then probably he will suggest that we write test cases for all possibilities and if you are part of team where everyone is young or most of them are in their midlife, then probably they will not be bothered and will ask you to write tests that shows the code is working as expected. I don’t think there is anything wrong with this approach either, however I feel it’s good that more unit tests we write, better the shape of project in the downstream phases, however this needs to be done correctly and results should be obviously visible. It does not make sense that we do unit testing for every piece of code flow and there are thousands of defects logged by the QA in the later phase. This just don’t make sense economically nor from the management prospective.

So probably I will focus on areas which I feel developers need to focus in their unit testing in this post without getting themselves buried in the art of functional testing,

There are infinite number of ways the code might fail, it might fail due to environmental changes, code might fail due to data changes or it might fail due to real bug in it. All these conditions happens all the time in various environment. So it’s practically not possible to know the failure mode beforehand. However being the developer of the code, we do assume that our code will be working will be working certain fixed environment with certain fixed perquisites for it to run. So it’s always better that we do some assumption and use our time judiciously for writing tests which reflects real time behavior.

I would suggest each of the unit tests exercised on the code under test should minimum show that.

  • The output given the code is correct and it does give us expected results.
  • Extreme boundary conditions for the input values are handled correctly.
  • Error handling is done appropriately by the code.
  • Tests should exercise the performance of the code under test

Maybe in next post I will come up with proper example to show as how to prepare test cases for each of the above conditions. We need to ensure that our unit tests are lean and thin in nature and we need to test just enough code.

Technorati Tags: ,

Tags: , ,

Unit Testing – 10 Good Reasons to Avoid It

July 20, 2013 by kiranbadi1991 | Comments Off on Unit Testing – 10 Good Reasons to Avoid It | Filed in Development, Scripting

I have been participating in the unit testing discussion for quite some time and does know that Unit testing is considered as one of tools which can increase the quality of the code which in turn improves the quality of the product, but still lot many people shy away from writing the unit tests. Couple of year’s back I had asked couple of experienced developers as why they don’t always write unit tests, and I got some of below interesting answers,

  1. Clients do not pay for Unit tests since unit tests are never part of agreed deliverable.

When client hires a developer to write some functionality, rates are agreed and paid for the functionality developed by the developer. Clients in most of the cases do not really bother as how developers write their code, what type of art they use to write and develop the functionality , all clients requires is working functionality. I would say it’s fair enough expectation from client. However when IT is your long term business or your business depends heavily on IT than probably you don’t want to skip unit tests. I suggest keep an on this blog for more my thoughts in coming posts or probably you can ask some veteran who is in business of coding or in business of developing products from scratch. IT is all about code and nothing else.

2. Unit tests do not assure the quality of your code completely, we still need QA to test the code or functionality.

This is another good reason for getting rid of unit tests. There are certain types of tests which most unit tester don’t cover for various reasons. Functional Testing, System testing etc. etc. are some of the types which are not covered by current existing practices of unit testing. However technically speaking, I believe unit tests can be extended to do Functional Testing, System Testing or Performance Testing. However if you are writing unit tests, you should probably be able to cut down the QA cycle by at least 30 to 40% , if you are not able to achieve even close to 20% , then probably your unit tests are not real unit tests.

3. There isn’t enough time to write unit tests.

This is another very good reason for not writing unit tests. Probably there isn’t time to write tests because time is just not accounted for in Project Management Plan. Most Project Manager I have spoken or seen, never included or tracked the activities of Unit tests. So even if you want to write it, probably you will not have time to write it since it’s not there in project schedule.

4. Its pain to write tests when requirements are changing.

This is fairly true reason. Requirements keeps on changing and with change, it adds over heads to all teams. It’s the way life works in IT. The thumb rule of IT is whenever requirements stops, growth stops. Changing requirements is the only way to see that company is making an attempt to grow at least for those whose core business is IT.

5. It’s much appreciated to develop the functionality and toss the code to QA.

I personally believe in having rock star developers and superstar testers in a team. So I would appreciate if developers can focus on developing functionality and testers focus on unit testing that code base. However I also believe that developers needs to toss the bare minimum working code to QA that does what it’s supposed to do. Things that code is not supposed to do , things that makes code to do what it’s not supposed to do, things what code does when it’s not supposed to do etc. etc. can be taken care by testers at the code development phase itself. However most unit test guru’s out their will not favor this approach. They expect developers to test their code for its accuracy by exercising both depth and breadth of code. They believe if I have written the code, only I knows its intent best, so only I can test it in best way. Probably I believe this thought process is the one which killed unit testing in the first place.

6. We do not have robust libraries out there still which can test every bit and pieces of the code.

One of things which I always wondered what if I am using the JDK for developing my applications, do oracle provide me some help as how to unit test their classes or probably if I am using .net framework, is there any guidance coming from Microsoft as how to unit test their .net framework classes ?. This may sound like naïve thoughts, but as we get into the lower level details, it’s just more than calling the methods or checking their return values. In short there is not enough material available to get best out of unit tests.

7. They do not test the end to end integration of systems.

Unit testing was born to test smallest bit of code. Integration testing or system testing involves lot of dependency, and also lot of other work which extends beyond the developer’s desk at times. As I said earlier, unit tests can be extended to do integration tests, system tests etc. etc. I believe in extending unit tests as it will save your lot of downstream QA effort. However it needs to planned and executed properly.Probably its time for unit system tests and unit integration tests.

8. In few cases technical complexity of the code restricts the testability of the feature at the code level.

Well this statement is also true, however with growth of agile practices, lot of people believe that if your code cannot be tested, then probably it’s a bad code and should not get into production. There might be few exceptions to this like using private methods for security purposes etc.

9. There aren’t enough people to who has knowledge or skills of doing unit testing.

Skilled resources are always hard to find. However I believe that existing skillsets of QA can be leveraged to do Unit testing. Anyone who prepares the script should be able to write Unit tests. It might take time to learn the trick of the trade, but they should be able to do it.

10. Unit testing is for Young and Rookie Developers.

I had seen lot many young people (1 years to 5 years development experiences) doing unit testing and experienced ones writing the code base. I don’t know as why only young developers are made to write unit tests and experienced one shy away from it. Probably they don’t want to get associated with anything which has word “test” associated with it.

I am sure there could be many more reasons in addition to above which I might not be thought about now. But I still feel Unit testing is one core skills which can improve the quality of the product with minimal investment. It’s just that there is not enough guidance and awareness among the masses and probably that’s reason we come up with intelligent ways to avoid it.

Tags: ,