Unit Test Case Guidelines

What is unit test?

Unit test is the software code written to test one unit of code. Usually there is a unit test against each method of your actual code because method is representing one unit of code.

Guidelines for writing unit test

  • One to one mapping b/w class and test class.There should be one to one mapping between your actual class methods and test class test methods

Class A{

method1(){}

method2(){}

}

Class Atest{

testMethod1(){}

testMethod2(){}

}

  • Test cases should be environment independent that is test code should not depend on pre-environment settings to pass. For example there is a method called IsUserLogin() which reads user info from a already setup DB having some user entry that test case is depend on. If this test case run at some other DB which doesn’t the user entry then test case would fail even though the code would be working fine.Database is the one factor of environment settings. There are many environment which includes Web/EJB container, JNDI settings,windows Registry, etc.There are many third party frameworks available to provide the support of separating your environment for test case these frameworks includes DBUnit, ServletUnit,HttpUnit, Jmock etc.
  • Write test cases for private method as well. Usually folks argue against this principle that private method is already tested through public method test case, but this argument is weak as in case of public method test failure you would have to introspect your code to find if the problem is in private method or in public method. Also in case of one private method failure there might be failures in all those public methods that are using the private method.

Unit Test Antipatterns

  • The Liar

An entire unit test that passes all of the test cases it has and appears valid, but upon closer inspection it is discovered that it doesn’t really test the intended target at all.

  • Excessive Setup

A test that requires a lot of work setting up in order to even begin testing. This can make it difficult to really ascertain what is tested due to the “noise” of all of the setup going on.

  • The Giant

A unit test that, although it is validly testing the object under test, can span thousands of lines and contain many many test cases. This can be an indicator that the system under tests is a God Object

  • The Mockery

Sometimes mocking can be good, and handy. But sometimes developers can lose themselves and in their effort to mock out what isn’t being tested. In this case, a unit test contains so many mocks, stubs, and/or fakes that the system under test isn’t even being tested at all, instead data returned from mocks is what is being tested.

  • The Local Hero

A test case that is dependent on something specific to the development environment it was written on in order to run. The result is the test passes on development boxes, but fails when someone attempts to run it elsewhere.

  • Success Against All Odds

A test that was written pass first rather than fail first. As an unfortunate side effect, the test case happens to always pass even though the test should fail.

  • Hidden Dependency

A unit test that requires some existing data to have been populated somewhere before the test runs. If that data wasn’t populated, the test will fail

Unit Test implementation using XUnit

Xunit are the basic unit testing framework available almost in all languages with X replacing the initial letter of the language. e.g

  • JUnit is a unit testing framework for java

  • CPPUnit is a unit testing framework for C++

  • PHPUnit is a unit testing framework for PHP.

  • NUnit is a unit testing framework for dotnet.

  • FlexUnit is unti testing framework for Flex.

  • AntUnit is unit testing framework for AntScripts

  • DBUnit is a unit testing framework for database. It can be used in conjunction wit Junit for inserting seed data in database.

All these framework required us to implement following two methods making a test. These are:

  • Setup() – In this method we usually write the setup code that is necessary before running the test case

  • Teardown()-In this method we usually write the code to undo the things we performed insetup method.

Following are the methods that are exposed by these frameworks:

  • assertTrue(errorMessageForFailure, expectedBooleanResultOfSomeCondition which must be true)-This would fail if the expected result is false printing the message on console which is passed in the first argument.

  • assertFalse(errorMessageForFailure, expectedBooleanResultOfSomeCondition which must be false)-This would fail if the expected result is true printing the message on console which is passed in the first argument.

  • assertEqual(errorMessageForFailure, expectedResult, actualResult)– This method compares two values of which first one is the expected one and the other one would be the actual value return from some method. If two values compared are not same then error message is printed on the console which is passed in first argument of this method. This method comes with other overloaded methods having almost each datatype to compare.

  • assertNotEqual(errorMessageForFailure, expectedResult, actualResult)– This method compares two values of which first one is the expected one and the other one would be the actual value return from some method. If two values compared are same then error message is printed on the console which is passed in first argument of this method. This method comes with other overloaded methods having almost each datatype to compare.

  • assertNotNull(errorMessageForFailure, actualResult)-This method assure that actualResult is not null. If it is null it prints the error message on the console passed in first argument of this method.

  • assertNull(errorMessageForFailure, actualResult)-This method assure that actualResult is null. If it is not null it prints the error message on the console passed in first argument of this method

Advertisements

One thought on “Unit Test Case Guidelines

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s