The purpose of “UNIT TEST” is understood by various people differently. I would suggest not to rely on any of the specific articles on internet and not follow those materials blindly. It is always good to go through various materials and apply your experience on top it or listen to suggestions of other skilled persons. And mainly consider nature of your project, since most of the expectations vary from case to case.

Unit test is all about verifying known functionalities coverage and expected exception coverage. Unit test doesn’t identify every error in the program, unit testing by definition only tests the functionality of the units themselves. Therefore, it will not identify integration errors or broader system-level errors such as functions performed across multiple units, or non-functional test areas such as performance.

Unit testing finds problems early in the development cycle. This includes both bugs in the programmer’s implementation and flaws or missing parts of the specification for the unit. The process of writing a thorough set of tests forces the author to think through inputs, outputs, and error conditions, and thus more crisply define the unit’s desired behavior.

Unit tests are also crucial to prevent regressions when you modify or refactor older code. They do not prove your change hasn’t broken old code but they give you a lot of confidence.

We advocate writing tests as a developer writes new code. Unit test do not eliminate bugs, but they dramatically reduce the number of bugs as you add new features. QA (Manual or Automatic) is the final authority to certify the quality of the developed system or unit.

Unit tests reduce the cost of change – Tests make it easier to change software because you have confidence that changes do not break existing functionality. When you have good test coverage, you have confidence to explore new design ideas without fear of introducing new bugs.

“In this description I am not considering TDD or BDD, which is totally a different subject”

For successful unit test implementation, following points need to be considered:

  • All positive and negative functional scenarios should be available in the functional document for developers.
  •  Independent reusable components must be verified by unit test cases.
  • Number of developers and number of teams involved in the project – if the same task is modified by various developers, then there is greater need for unit testing.
  • Skill level of developers – if  a developer considers all the positive, negative, non-functional and system related expectations during programming, then the need for unit test becomes less important
  • Business or Domain of business. – There are certain businesses such as banking, health care, 21CFR Part 11 etc.  that need to arrest all the possible gaps during development, which need to focus more on unit testing
  • Duration of development life cycle – Assume that there is a planned stiff deadline for a project, assume one month, in this context if you expect three months’ efforts for unit test, this will lead to issues, which will mess up the complete project. Consider only unit cases that are very important and that can be accommodated with in the month
  • External/internal integration of systems – need to think of mock objects etc.
  • Project cost – Assume development cost of application is $10K and development cost of test case is $50K. Do you think it is good to have costly test cases? Is there any benefit out of cost?

Don’t do unit testing for the following purpose:

  • Just for the sake of company practice and process
  • To portray that we are genius programmers
  • Develop unit testing as a bigger project, which leads to unnecessary maintainability issues
  • If you think you are going to spend more than 20% (subjective) of development time for unit test, then it is misunderstood
  • Forwarding URL or article to your developers without conceiving the complete picture.
  • Rely only on internet articles
  • Assuming UNIT test will replace TESTER’s/QA’s work
  • Don’t try to force your understanding that may be not be right
  • Laziness or attitude that prevents one from taking others’ suggestions or opinions
  • Don’t discuss with resistive mind.

Summarizing the above points, please think about your project scenario and need as well as the duration of the project before you set the expectation about unit testing.


Design Patterns GOF,Enterprise and Architectural

Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object’s internal state
Observer A way of notifying change to a number of classes
State Alter an object’s behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change