Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] Using JUnit to test database access code

Expand Messages
  • Emily Liu
    I actually did some tests by using JUnit on the database access code. I created a test database with only one table in it. The test database contained every
    Message 1 of 2 , May 31, 2000
    • 0 Attachment
      RE: [XP] Using JUnit to test database access code

      I actually did some tests by using JUnit on the database access code. 

      I created a test database with only one table in it.  The test database contained every possible test value such as null or empty value in columns.  My test code was running against my test database.  When I added a new test case in my test code, I added a corresponding test value into the test database too.

      Hope this will help you.

      Emily Liu
      CenterSpan Communication Corp.
      (503)615-3238

      -----Original Message-----
      From: mgh520@... [mailto:mgh520@...]
      Sent: Wednesday, May 31, 2000 7:06 AM
      To: extremeprogramming@egroups.com
      Subject: [XP] Using JUnit to test database access code


      I'm confused about how to best write JUnit tests for Java code that
      is mainly driven by data in a database.

      Just to have some tests, I started out writing them with hard-coded
      values.  For instance, if a method reads a database table and returns
      objects representing the data, I would have a test that would verify
      that 3 objects were returned and that the data in each one was what I
      knew it should be.

      However, I knew from the start that this wasn't a final solution
      because the data is subject to change and by simply adding a row to
      the table, my test will fail because it was expecting 3 rows, and now
      there are 4.

      So from here I started writing tests that would make their own JDBC
      connection to get the data from the table, then compare it with the
      objects returned by the code being tested.  I could now do things
      such as a "select count(*) from ..." and use this value to verify
      that the correct number of objects were returned, and then select the
      data itself and verify that the returned object contains the same. 
      This relieved the dependence on hard-coded data in the tests, but it
      also made the tests much more complicated and the code is not easily
      understood, which makes it hard to add or update tests.

      Also, how do you test for conditions such as a null or empty value in
      a column?  You have to add data to the table just for the tests. 
      I've briefly considered having the setUp() of the tests insert rows
      and the tearDown() remove them again, but I worry then about a
      program crash or other problem that might cause tearDown() not to be
      executed and leave the data in an inconsistent state.

      Does anyone have any experience with these sort of tests and has any
      one found a good way to write them?  Thanks!



      To Post a message, send it to:   extremeprogramming@...

      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

      Ad-free courtesy of objectmentor.com

    • Morris, Chris
      ... I do this. In the first place, our key fields are strings, with a custom ID generator (compared to, IME, more traditional integer incrementing IDs), which
      Message 2 of 2 , Jun 1, 2000
      • 0 Attachment
        > I've briefly considered having the setUp() of the tests insert rows
        > and the tearDown() remove them again, but I worry then about a
        > program crash or other problem that might cause tearDown() not to be
        > executed and leave the data in an inconsistent state.

        I do this. In the first place, our key fields are strings, with a custom ID
        generator (compared to, IME, more traditional integer incrementing IDs),
        which allows me to prefix each test record's key value with "TST" - they can
        be easily identified and removed in the event tearDown fails. In addition,
        setUp first calls the same DeleteTestData that tearDown calls, to ensure the
        test data is clean before the test begins. If you can't control the key
        values - use some other value in your row to definitively determine if the
        row is a test row, so you can clean it up later. Or ... setup a separate
        database that will only ever be used for test data so worst case you can
        simply "DELETE FROM Table"

        A better suggestion I caught in an earlier thread is to start a transaction
        in setUp, then roll it back in tearDown. This is nice, because the data is
        never committed. If an error prevents tearDown from ever being hit, rollback
        won't be called, but no code committing the data will be called either. This
        could be problematic, however, dealing with potential nested transaction
        issues. (e.g., I use ODBC to connect to SQL Server - ODBC does not support
        nested transactions, I have to roll my own nesting support). If you have
        transactions in the production code you're testing, they may not work well
        inside the setUp/tearDown transaction.

        > This relieved the dependence on hard-coded data in the tests, but it
        > also made the tests much more complicated and the code is not easily
        > understood, which makes it hard to add or update tests.

        Just a comment. If you're just starting - this portion of writing the
        fixture code will be painful and, in the short term, not productive in terms
        of writing production code. But the time invested now to have a good fixture
        setup is worth up. Keep plugging away.

        Keep refactoring your test code, too. Your test code is likely to be more
        messy than your production code, but be sure to take advantage of all the XP
        tips for setting up your test code as well.

        Another comment, try to structure your code so that your read/write of the
        database is minimized. That way, you will only need a few tests that
        actually involve the database. If the rest of your code refers to data in
        memory that was placed there by your data access code layer, all the tests
        for the rest of your code can use stub data, and you can avoid
        reading/writing from the database for all those tests.

        Chris
      Your message has been successfully submitted and would be delivered to recipients shortly.