Hi Keith, I agree that the test cases should be eventually executed against the actual database, for this reason I was suggesting to have a config file that allows to switch the database used by the test cases.
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 ------------------------------------------------------- "Keith Pierce" <[EMAIL PROTECTED] m> To Sent by: Developer mifos-developer-b <[EMAIL PROTECTED] [EMAIL PROTECTED] net> ceforge.net cc Chico Charlesworth/Ireland/Contr/[EMAIL PROTECTED] 10/03/2008 13:37 E, Roberto Musso/Ireland/Contr/[EMAIL PROTECTED], Sam Birney Please respond to <[EMAIL PROTECTED]>, Developer Adam Monsen <[EMAIL PROTECTED]> <mifos-developer@ Subject lists.sourceforge Re: [Mifos-developer] Mayfly .net> replacements 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/ ------------------------------------------------------------------------- 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/
