Unit Testing: Back-end Framework

and Process

August 20, 2009

Agenda

• Motivation

• Testing Framework

• Process

• Limitations

• Conclusion

Motivation

• Reduce bug count and cost of fixing a bug once its been shipped

• As the team grows we need a regression suite that protects against breaking existing functionality

• Goal is to make unit testing fast, easy, and part of the development process without lengthening release time

Testing Framework

• Mostly server side testing

• Does not require a DB, we setup data conditions in memory at the start of the test suite

• Isolate testing to each code layer

• Stub Methodology: test one class and the rest of the classes it depends out get “stubbed” out

• Stub classes still inherit from interfaces, but its methods always return the same values or it might have a generic data structure used for storage.

• Mocks require steeper learning curve for learning APIs specific to a framework

• Stubs resemble existing class hierarchy

Process

• Testing Flavors: TDD or testing all code at the end; neither works for Mint’s development process or speed, especially when juggling multiple projects

• What works:

• Include unit testing in project time estimates

• Design all front and backend interactions and classes, then split the problem up into deliverables

• Code one section e.g. creating, updating, deleting a monthly budget then write test cases, then move on to accrual budgets, and then move on to tangential components like alerts for budgets.

• This methodology keeps up with the pace of design changes

• Don’t have to constantly re-write test cases

• As the design changes you can incrementally change test cases and add more as needed

Limitations

• Harder to be as rigorous when juggling multiple projects

• Does not catch issues between tiers, still requires integration testing

• e.g. DAO methods or DB issues won’t be tested

• Race conditions between web tier and other tiers

Conclusions

• Once the suite is setup its easy to add test cases

• Just one approach – open to exploring other options

• Suggestions for frameworks or methodologies to use?

• Next steps:

• Exploring file formats to store and reuse test data e.g. Castor

• Refactoringstubs to make them cleaner and usable by others

• Searching format to describe data e.g. text or a flatfile that doesn’t require ramp -up