Roadmap. In terms of quality, your software development lifecycle boils down to your quality roadmap. What does your picture look like and whats it worth to your organization? Start with a template…
- Unit tests
- Continuous Integration
- Automated build deployment to test machines (build farm process)
- Test environment standards (shared mounts, file system conventions, shared user accounts)
- Test case best practices: (documentation, test case format, import and library reuse, model based test script generation, data driven testing)
- Test qualification: Feedback mechanism, Reinforcement processes
Professional track athletes and runners alike are familiar with the term parloffs. The idea is that, at any moment during the workout, at least one group is running. The practice squad divides into various groups where one group runs a lap and, upon completion, the resting group then starts their lap around. Meanwhile, the group that just completed can rest and will start up once again when the currently running group completes its lap. I’ve talked about this living breathing machine in a previous post
- Test Driven Development
- Code check-in activates Continuous Integration (eg Cruise Control to perform build and testing)
- User notification of build status
- Deploy build on test machines
- Trigger functional test automation
- Smart testing will optimize test execution (eg if basic tests fail, there’s no sense in running a more complex test)
- Results! Results! Results! Report Results!
Why Unit test your java code?
– Remove bugs when its cheaper to do so (testing units is much quicker than debugging systems)
– Eases refactoring and tuning
– Unit tests can be used as training material and documentation for new developers and testers
– Popular tools for Java include JUnit and TestNG
– Java unit test: a java method that test the behavior of an individual unit, a module, or an integrated set of modules
– Skill: Time investment required in learning to use a unit testing tool
– If code is not designed for testability, then java unit testing is more difficult
– Dependency isolation and mocking is difficult (more details in a sec)
How to create your unit tests
1. Create a source folder in your java project called “test”
2. The packages within “test” should be the same as those in “src”
3. JUnit test should be named
4. Test methods should be called test
* testing that singleton always returns same object
public void testGetInstance()
Search search = Search.getInstance();
Assert.assertEquals(“Asserting that singleton retrieves same object”,
Having tests doesn’t amount to much…
Its like saying you workout. If your workout is a wimpy 10 minute routine that doesn’t stress your body, then your workout is worthless. Your tests must be meaningful and here are some best practices to add meaning to your java unit tests.
– Ease of creation and execution
– Complex testing
– Verifying exceptions: Do you verify that an IllegalArgumentException is thrown?
– Data driven testing
– Database testing (DBUnit): http://dbunit.sourceforge.net
– XML Testing (XMLUnit): http://xmlunit.sourceforge.net/
– Vary input values
– Vary internal states
– Mock Objects
– EJB Testing
Isolating Code for testability
1. Dependency Isolation: class looks up a mock object via a static call
2. Injection: mock reference is passed into the class’s constructor
(sorry, but you gotta click on the thumbnail to view the coding differences between dependency isolation and injection)
Example of JUnit4 test
- Source Under test (src/com/sogwiz/searchapp/Search.java)
- Test class (test/com/sogwiz/searchapp/SearchTest.java)
Database Unit Testing….hmmmm
A true unit test doesn’t access the database or file system. This would be more of an integration or system test. Database mocks should be used to test your data accessors in TRUE unit testing.
Whatever, this is how we’ll do some integration / system tests of the database.
- Restore db to known state
- Use perl or DBUnit
- PRO: simple, clean, and easy
- CON: time expensive for each test execution
- Use POJO’s created by reading from XML representations of your persistable object
- PRO: quick and fast test execution as data setup is blazing fast
- CON: complex to create this framework that loads POJO’s from XML files
Conclusion about Unit Testing
How and Where to Start? JUST DO IT!
- Perform unit testing on a new project or feature
- Creating unit tests on pre-existing projects is time consuming and may involving decoupling legacy code, possibly introducing risk into your project
- Focus on basic code units first
- Basic means any classes that are isolated and have very few dependencies Create white box tests harness iteratively and make it as simplistic as possible
- Systematically discover and deal with challenges
- A former colleague of mine, Kevin Lawrence, wrote an awesome article about creating a simplistic evolving test harness.
- Expect challenges and road blocks
On with our journey through the roadmap. I’ll set up links to my post regarding Continuous Integration (Part2) and FVT Quality Automation(A topic dear to my heart,Part3) in upcoming posts. I got the content – its just that formatting and reformatting everything is a pain, a pain I enjoy kind of like the pain from love.