Testing with an in-memory database would likely improve performance. However, doing that and nothing more doesn't solve the real problem, namely that many unit tests shouldn't be accessing a database at all, but are doing so simply to populate business objects in order to test some unit of code. Such tests unnecessarily slow down unit testing, and I fear that even with an in-memory database, the unit test suite will still run so slowiy that the purpose of rapid unit testing as part of an agile process is defeated.
Moreover, if the purpose of a unit test is to test something about the database, running the test against an in-memory database can give the developer some degree of confidence that the database is doing the right thing, but prior to committing any code all tests have to be run against the database to be used in production. Ultimately, the only way out is to refactor the application to be more strongly layered, perhaps including something like a repository layer that would allow the developer to mock the database when unit testing business logic above the database layer. Then, unit tests need not hit any database, whether in-memory or not. Keith On Fri, Mar 7, 2008 at 6:37 AM, Massimiliano Parlione <[EMAIL PROTECTED]> wrote: > Hi Van, > from our side there is no bandwidth to do this change. We all agree that > we > need to review the overall architecture of the test cases. > > Personally I think all the test cases should be executed against an > in-memory database such as Derby or others as suggested by Stephen to > execute the tests quickly and without requiring an external database > installed on the machine. > I addition the test suite should have a configuration file that allows to > switch from the in-memory database to the database supported by the > product. In this way it is possible to verify if the code is actually > working with MySQL without slowing down the development activity or the > build server. > > The current situation in not brilliant because we have some tests executed > against myFly and others against MySQL. > > - Would you like to track this issue on the issue tracker ? Otherwise we > can add this activity for the next release in the product roadmap in the > unscheduled features section (Architecture enhancements) > We could add something like this at the end > (http://mifos.org/developers/roadmap/product-roadmap): > > - test cases re-engineering (choice of an in-memory db, decrease the > execution time, ....), > > Regards, > Max > ----------------------------------------------------- > Massimiliano Parlione - > http://w4.ibm.com/bluepages/html/[EMAIL PROTECTED] > Current Project: https://w3.webahead.ibm.com/w3ki/display/MIFOS/Home > Building 6, Innovation Center, Meeting Room 1 > IBM Technology Campus > Damastown Industrial Estate > Mulhuddart > Dublin 15 > Ireland > Phone (external): +35318152394 > Extension Number: 512394 > IBM International Holdings BV registered in Ireland with number 903924. > Registered office: Oldbrook House, 24-32 Pembroke Road, Ballsbridge, > Dublin > 4 > ------------------------------------------------------- > > > > "Van > Mittal-Henkle" > <[EMAIL PROTECTED] To > ndation.org> "Stephen Horgan" > <[EMAIL PROTECTED]>, Chico > 06/03/2008 23:16 Charlesworth/Ireland/Contr/[EMAIL > PROTECTED] > E > cc > "Sam Birney" > <[EMAIL PROTECTED]>, > "Adam Monsen" <[EMAIL PROTECTED]>, > Roberto > Musso/Ireland/Contr/[EMAIL PROTECTED], > Massimiliano > Parlione/Ireland/[EMAIL PROTECTED] > Subject > Mayfly replacements > > > > > > > > > > > Hi All, > > I was reviewing the discussion on irc from yesterday about Mayfly, MySQL > and HSQLDB. I definitely agree that it would help us to move forward > faster if we did not have this dependency. On more than one occasion I > have come close to diving in and making this change. > > One suggestion is that as a first step you might try generalizing the > code such that we could plug in MySQL as a replacement for Mayfly in the > current tests, since we know will MySQL will work. Of course, this will > be slower than an in-memory db, but at least we know that it can be used > to unblock us if we run into Mayfly issues. Once the code is general > enough to plug in a MySQL replacement, then it should be in a state > where a HSQLDB replacement could also be tried. > > --Van > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
