What, Why and When Test Cases?

Overview

Test Driven Development(TDD) has once again emphasized the need and importance of test cases during development. But test cases and its’ use in development differs very much from normal software development and a whole new, beautiful and elegant process. This article helps us to understand test cases(What), its’ importance (Why) and where should it be implemented(When); to yield utmost benefit.

What is test case?

A test case, in software engineering, is a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do.

-wikipedia.org

In simple words test case is an art of testing a unit of work.

Why Test cases or what are the advantages of test cases?

  • We, developers always test our piece of code in one way or another but we don’t realize it. We test either by running the application, writing output in command line or there might be other ways. Writing test cases only increases this process or testing by increasing efficiency and ensures not to test the entire cases again when we again make slight changes.
  • It helps in reducing bugs. Once we include test case for a condition, it ensures that the same condition is checked every time and the block of code always behaves accordingly.
  • It helps us to understand code quickly. It acts as a good documentation.
  • It is one of the quickest ways to debug. From test cases we can easily debug the block of code we want, instead of running the entire application and going down to the particular block of code.
  • TDD (Test Driven Development) if followed, forces us to think before coding. To writing test cases, one has to understand the requirements clearly.
  • Gives us the confidence that our changes have not affected the existing features.
  • Running entire test cases before starting work ensures that the application is in stable state. The same holds true while we make changes.
  • Refactoring becomes a piece of cake. We know that it just shouldn’t break any test cases.
  • It increases the standard of the code. To be able to write test cases, different programming patters and principles have to be followed.

When to write Test Cases?

We must always have the tendency to write test cases before or during development. But even writing test cases after development is better than no test cases. There can be some point when test cases don’t look desirable. Some of them are listed below:

  • When it is too simple .There is no point in writing test cases for simple cases like domain object as it doesn’t add any value to our code. These cases are trivial.
  • When it is too difficult. It is agreed silently among developers that if writing it requires huge amount of effort, it is best not to write it. Generally, it should be simple and easy to understand.

Feature of good Test Cases

  • The number of test cases should be just enough. Unnecessary and large number of test cases just increases the build time.
  • Test cases should be fast. We need to run them frequently, if it requires a huge amount of time it slows down development .So either it has to be re-factored or re-written.
  • It should be simple and easy to understand.
  • Generally a test case should check a feature. We shouldn’t include many features in a single test case because when a features break down we know exactly what has broken down and the fix is pretty straight forward.
  • Test cases should only be used in development environment.
  • It should always be green i.e. passing when you are off working.
  • It should be independent. One test case shouldn’t be dependent on other.

References:

  1. http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort
  2. http://www.onjava.com/pub/a/onjava/2003/04/02/javaxpckbk.html
  3. http://blogs.telerik.com/justteam/posts/12-05-17/why-i-hate-unit-testing.aspx
  4. http://simpleprogrammer.com/2010/12/12/back-to-basics-why-unit-testing-is-hard/

Share this article


About the author



Previous post