The Unit Testing Challenge Agile Testing

When writing unit tests for a piece of software, the first decision that needs to be made is the granularity of the test units – if the units are too coarse, there will be a large number of tests for any given unit of code and the result will be hard to manage. If the units are too small, it will be difficult to relate the tests back to the software requirements in any meaningful way.

In order to support both unit testing and general maintenance, any well-designed system should be composed from a set of readily identifiable, cohesive units that individually perform well - defined functions and interact with each other via simple interfaces that hide implementation complexity.

In our case, the existing system was constructed from a set of components that were implemented using the Enterprise JavaBean (EJB) component standard. These components were a logical choice for our unit testing and, consequently, the vast majority of our unit tests were written at the component level.They could easily be verified against system requirements through our software architecture model – a piece of high-level(and lightweight) design that charted the structure and interaction of the components against system requirements.

Despite being an obvious target for unit testing,there were no existing tests in place that we could use, and we encountered a number of challenges when creating new ones. These included:

  • finding a way to run tests against their target components without the complexity and speed implication of automatically deploying them to the Websphere application server each time they were executed;
  • introducing a mechanism that allowed a component’s dependencies to be selectively replaced for testing, enabling it to be tested in isolation of other components;
  • creating tests that were precisely targeted at particular features without unnecessarily constraining the way that the rest of the system worked;
  • testing of poorly factored existing interfaces,whose behavior was heavily dependent on (although not immediately apparent from)the parameters passed to them;and
  • trying to understand the purpose of existing code that, due to being outside the scope of our project,had no available requirements documentation.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics