spring apps should be inherintly more UNIT testable meaning that each service should be constructed with mock objects or other lightweight implementations and not rely at all on spring. relying on spring to construct and weave together your dependencies is classified as an integration test, which can be slower.
-----Original Message----- From: Micah Craig [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 10:29 AM To: Maven Users List Subject: Re: problem *not* forking unit tests First, thanks for the quick reply, and a thousand apologies for the duplicate post (more email addresses than I know what to do with.) I appreciate that not forking is a somewhat fringe use case. The problem that we are facing is that as a Spring based project, we face a non-negligible initial startup cost (loading our Application Context), which, in a non-forked environment, we can avoid repeating for each test. When forking, the time to run all our tests balloons dramatically (hours, not minutes). Can you provide any insight as to how we might alleviate this burden (Test Suites seem a possible option, but we worry about maintenance overhead)? Thanks very much, -micah Ryan Sonnek wrote: >this question comes up so frequently, and the answer is always, "Junit >tests should be forked." Can someone PLEASE change the default behavior >of the test plugin to fork unless it's overridden? It would save on the >constent confusion in this area. > >-----Original Message----- >From: Julien Kirch [mailto:[EMAIL PROTECTED] >Sent: Tuesday, November 23, 2004 3:21 PM >To: Maven Users List >Subject: Re: problem *not* forking unit tests > > >Hi Micah > >I think the test forking law is "thou shall fork", not forking is a real > >classpath mess between maven and project classpath (and caused your >problem), I don't think not forking is ever a good idea. > >Julien > > >Micah Craig wrote: > > > >>Hi, >> I just upgraded from rc1 to 1.0.1, and suddenly, I can't run JUnit >>tests un-forked (maven.junit.fork=no). Failure output is below. >> >> >Could > > >>this be some sort of mangled classpath issue left over from the >> >> >upgrade, > > >>or is something more sinister afoot. Thanks, >> >> -micah >> >> > > > >--------------------------------------------------------------------- >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]
smime.p7s
Description: S/MIME cryptographic signature
