Final lessons learned Agile Testing

In summary,we learned a great deal from the project.Some specific lessons that we will be taking to future projects include:

  • Use mock objects to enable unit tests to focus on the unit of code under test and nothing else.
  • Pay as much attention to the design and quality of tests as you would to production code.
  • In each test, check as much as necessary but no more.Carefully consider the scope and purpose of each test and think carefully about the most effective way to implement it without constraining system code.
  • Adopt test-first or test-driven development to ensure that developers are disciplined about test writing and that they mentally separate function from design.
  • Ensure that tests can be traced back to system requirements or that the requirement being tested is immediately clear from the test.This makes code easier to audit and maintain.
  • Adopt and follow an effective change management process and consider the use of a change management tool.

Finally,following the conclusion of the project, I put some effort into evaluating how our development approach could be improved for the future and in particular how we could make more effective use of mock objects. I drew up a shopping list of features that my ideal mock objects framework would have. A summary is as follows:

  • a simple mechanism to support flexible parameter matching–the testing of some parameters or attributes of parameters,but not others;
  • the production of messages when mock expectations fail that allow the developer to determine exactly what has failed and why – ideally pinpointing both the test and the expectation;
  • allowing for creation of mocks against existing classes or interfaces;
  • supporting the ability to test calls to class constructors;
  • being simple to use and maintain;and
  • allowing the relaxation of call sequencing checks,if required.

I evaluated a number of mock frameworks against these and other criteria.Most(including EasyMock)did quite well,but they fell short on one or two important points.I also had the idea that a mock objects framework could be simpler and more effective if it shifted the responsibility of evaluating expectations back to the test by using call-backs.This would allow the test developer to implement the most appropriate set of assertions for any given test.If an expectation was to fail,then the error report would point directly to that line of code.

This prompted me to write my own Java-based mock objects framework called SevenMock,which is now an active project on the SourceForge open-source software development Web site.As desired,SevenMock is a very simple piece of software but evaluates well against my stated criteria compared with the other frameworks that I investigated.It has a few restrictions of its own–it can only test against classes (not directly against interfaces)and it doesn’t support relaxed call sequencing at the time of writing.In practice, users have found that its restrictions are easy to live with and feedback has been generally positive.Additional feedback and code contributions via the SourceForge Web site are very welcome.

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

Agile Testing Topics