Select Page

How many words is your picture worth? (Part1)

by | Mar 22, 2008 | automation, java

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…

Development Quality

  • Unit tests
  • Reviews
  • Continuous Integration

FVT Quality

  • 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 . The idea is that your software lifecycle should be a clean lean living breathing machine with the following sequences of events:

  1. Test Driven Development
    1. Reviews
  2. Code check-in activates Continuous Integration (eg Cruise Control to perform build and testing)
    1. User notification of build status
  3. Deploy build on test machines
  4. Trigger functional test automation
    1. Smart testing will optimize test execution (eg if basic tests fail, there’s no sense in running a more complex test)
  5. 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
Tooling
– 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
Why not?
– 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 Test.java
4. Test methods should be called test()

/**
* testing that singleton always returns same object
*/
@Test
public void testGetInstance()
{
Search search = Search.getInstance();
Assert.assertEquals(“Asserting that singleton retrieves same object”,
Search.getInstance().toString(), search.toString());
}

———————————————————————–
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)
1. public Object search(String searchStr) throws NullPointerException
2. {
3. StringTokenizer strTok = new StringTokenizer(“,. “, searchStr);
4. if(strTok.countTokens()==0)
5. {
6. this.valid = false;
7. throw new NullPointerException(“Empty search”);
8. }
9. else
10. {
11. StringBuffer sb = new StringBuffer(“”);
12. this.valid = true;
13. while(strTok.hasMoreElements())
14. {
15. sb.append(getResults(strTok.nextToken()));
16. }
17. return sb;
18. }
19.
19. }

  • Test class (test/com/sogwiz/searchapp/SearchTest.java)
/**
* the @BeforeClass annotation will be executed exactly ONCE by the JUnit test runner
* @throws Exception
*/
@BeforeClass
public static void setUpBeforeClass() throws Exception
{
search = Search.getInstance();
}
/**
* the @Test signifies this method as a test
* the test method expects a NullPointerException to be thrown
*/
@Test(expected=NullPointerException.class)
public void testSearchNullPointerException()
{
search.search(null);
Assert.assertFalse(search.isValid());
}

———————————————————————–
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.

  1. Restore db to known state
    1. Use perl or DBUnit
    • PRO: simple, clean, and easy
    • CON: time expensive for each test execution
  2. Use objects instead of database
    1. 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
  • 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.

1

Submit a Comment

Your email address will not be published. Required fields are marked *