Re: [OJB-developers] JUnit Tests & MySQL / global IDs

[Thomas M. <tho...@ho...>]

hy !

Joa...@tp... wrote:

<snip>


 >
 > do we also need JUnit Tests for such configureable features as the global
 > High/Low ID Generator? The Problem here is the same as with JUnit 
tests for
 > the C/S-mode. We'd need to  modify OJB.properties to test these features.
 > We either make a general system for changeing specific configuration
 > entries for specific tests or rewrite the build.xml to re-run the tests
 > with several alternate configurations.


This may raise an interesting discussion of our testing strategy.
The JUnit evangelists will tell you that it is best practise to test
*everything*. Even getter and setter methods !
They generally also recommend to perform whitebox tests.

Using this approach you can achieve 100% code coverage for your tests.

The Approach I choose is not that strict:
- Most tests are highlevel blackbox tests that run against the public
OJB APIs. There are very little whitebox tests (e.g. ODMG lifecycle).
- The tests are usually coarse grained. coherent blocks of functionality
   ("use cases") are tested together.

Here are my reasons for going this way:
- The main aim is to assure that the API works properly for end-users.
- This is done by checking typical use case scenarios.
- I don't see realistic reasons why a getter or setter might fail.


Following this principle I suggest:
1. provide TestCases for the HighLow ID Generator,
2. don't write Testcases for the configuration stuff, write more
TestCases for 1. ;-)


 > Does Sourceforge allow running
 > automated regression tests on their system?


I don't think so. But afaik they provide nightly builds. But I don't
know if they support ANT builds.

  This way we'd be able to run
 > regression tests against several databases every day. If sourceforge
 > doesn't allow such things, we could do this on our internal system 
(we have
 > similar regression tests, along with auto-generated documentation for our
 > internal project) as soon as our server is back to live (right now he 
is in
 > a rather bad condition).
 >


As I see it the Junit tests are a thing each developer *must* do
individually before checking in code.
Project managers (like me) who assemble releases *must* run the complete
Junit testsuite before publishing new releases.

I don't think it's essential to have complete nightly builds. But of 
course I appreciate your offer!


 > [snip]
 >
 >>5. We currently don't have a proper change management system. But
 >>there is a excel file (todo.xls) in the base dir of the OJB-1-0
 >>project. Please add your changes to this file. This file is used to
 >>assemble the change log for new releases. Thus it is important to
 >>register all changes here ! (If you have an idea how to provide a
 >>better change management please contact me.)
 >>
 >
 > I suggest we don't use and excel file, for several reasons, some of which
 > are just my personal taste and might therefore not be inportant:
 >
 > - many people don't run Windows & those who do might not have Excel
 > (fortunately I (have to) use Windows and work and do have Excel 
installed).
 > - cvs can't give you a meaningfull diff of any Office document.
 > - security implications (cut & paste from/to office documents might copy
 > more than is visible)
 > - i don't like Excel ;-)
 >

I don't have Excel on my Linux box. But use StarOffice instead. It's 
free, cross-plattform, and can handle all MS-Office formats.
In fact the todo.xls was written from my StarOffice !

 > a simple text-format TODO might be an alternative. Granted, handling this
 > would be a bit more complicated, but at least everyone can do it. Another
 > idea for a changelog might be something along the lines of cvs2pl (to be
 > found at http://www.red-bean.com/cvs2cl/), I just recently found it and
 > haven't tried it, but it looks interesting.
 >
 > (I'll just update my changes there nevertheless, until we find an
 > alternative)
 >

IMO The best thing would be to have a live database hosted at SOurceForge.

cu,

Thomas