My unit testing is always single threaded anyway. I believe it's generally agreed that spawning threads in a unit test is an anti-pattern, so I avoid it. Although, admittedly I sometimes wonder how certain things can be tested easily without multiple threads.
Clinton On Wed, 09 Feb 2005 20:39:26 -0800, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > > > Hi all, I love Derby, but for unit testing it's just too slow. We used > > to use HSQLDB before iBATIS joined ASF, but I switched to Derby it > > because I wasn't sure if HSQLDB was compatible with the ASF license. > > There has been some discussion of adding a lower durability option to > Derby, which would allow much faster database creation etc. for unit > testing. Some internal testing flags already exist so I believe it's a > fairly small amount of work to externalize them in a rational way. Come > to the derby-dev list get involved to bring the issue up again (or fix > it yourself)! > > I'm not sure how hsqldb can be used as a test database, given that > multiple threads can overwrite each other, due to hsqldb only supporting > dirty read mode (no isolation). Thus if you see incorrect results it > seems you have to work out if hsqldb is the problem or your application. > > Dan. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
