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

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

Expand Messages
  • 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 1 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.

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