Hi Eric, Thank you for your reply. Your solution is definitly getting me there but I am still a little bit confused about dependencies of these projects.
Won't you run into a cirucular dependency issue between common test project and the library it support? From example, A, B are lib projects and C is app project, currently test setup classes are in A and B and are used by A and B test classes. So in theory, say you create a test project T, C will depend on A, B and T, T depends on A and B but A and B also depend on T. Maybe I am thinking too much? My head is definitly hurting %-| Thanks again, Pierre Eric Daigneault-2 wrote: > > Hi Pierre, > > The way I solved this for myself was to create a test project and put all > the common test code in it (as normal stuff, not as test stuff) then I > used > the test project in all other projects as a dependency. This way I have > access to the common test stuff. then to ensure that the extra project > (jar) does not make it in the final package I declared it as test in it`s > dependency scope. > > Extending the above principle I usually have two such jars for my > projects, > one that is all the common code used in all tests, there I place all the > generic stuff that can be reusable and is not specific. Another I will > put > all the mocks stubs and other such classes that are specific to the high > level project. This way all modules will have access to them and I only > code my stuff once. Great thing about this is that I can then code unit > tests on the test classes. May sound a bit excessive but when people > lives > depend on the code you produce a bit of paranoia actually help to protect > ones sanity. > > Of course for the stubs parts, to prevent circular dependencies you may > have > to separate the interface for your library from the implementation, which > in > time makes for more stable code. The downside is the multiplication of > modules. > > I hope this helps > > Éric :D. > > > On 10/1/07, Awaragi <[EMAIL PROTECTED]> wrote: >> >> >> Hi All, >> >> i hope that this question was not asked before as I am new to maven and >> to >> this forum. I am trying to build a multi-module project with three >> modules: >> libraries A and B and application C which depends on A and B. Libraries A >> and B have their unit testing classes which use a setup class to load >> testing resources, setup database connection, etc. This works all fine >> and >> nice for A and B. Now I am in the process of writting unit tests for >> application module C and i don't want to do copy/paste of the setup >> classes >> of A and B but I cannot find a way to make unit test classes of C to >> depend >> on unit test classes of A and B. >> >> I thought of moving some of these setup classes to main as a workaround >> but >> then i have to add quite a few test libraries to these modules and to the >> web-inf/lib folder of the final war file. Including a database jdbc >> driver >> is not acceptable so this workaround is not the way to go. >> >> Can anyone please help me with this setup? >> >> Pierre >> -- >> View this message in context: >> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166 >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12993076 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
