A recent project that I'm on involves a venerable app with as much technical debt as the US Government... and we need to add a feature. Solution: tests, tests and tests. More specifically if you don't know the different kinds of tests:
- Good old Unit Testing, easy to implement and understand, unless...
- You are getting used to mock objects (e.g. JMock or Mockito)
- You are testing database functionality and are new to DBUnit
- You are testing a web app or Servlet and are new to HttpUnit
- You're confusing unit testing (ONE module) with integration testing (multiple modules)
- Example: testing your Data Access Layer (DAL) with a dummy DB, like a local HSQL
- Integration Testing, usually implemented with a framework that ends in "Unit" so it's easily confused with unit testing. Integration testing integrates two or more components, everything from two classes to the entire app with a dummy DB. Due to this you can have multiple levels of integration tests, each testing more modules together. Examples include:
- Testing a servlet in HttpUnit's ServletUnit instead of your actual web container
- Testing your DAL with an "actual" database (whatever actual means to your project)
- Testing a fully created Spring bean with the real beans injected instead of mocks
- System Testing, this is tests of the entire system
- QA usually conducts manual system tests
- There can be automated ones as well with things like Selenium
- As an example for a web app, using a supported browser to use the app in the final web container and using the real database.
There is of course, much more to software testing, but these three are usually a good start. Heck, in many organizations / projects even using unit testing is new to people. Like Regan said: trust, but verify.
PS: There's a good post at EvilTester with a more philosophical approach to testing.
PS: There's a good post at EvilTester with a more philosophical approach to testing.
