Thanks guys for all the usefull insight. I guess there is no easy solution to this. I would have thought that test inheritance/composition was a common pattern that maven supported.
I guess I need to carefullu think about how to split modules or perhaps some very restricted code duplication should relax my head. This is a migration to maven/spring/struts2 from older technologies so it is a learning process and I wanted to make sure to adhere to maven philosophy. Pierre Eric Daigneault-2 wrote: > > Hi Pierre, > > It all depends on what you need to share. I discovered that a lot of the > code I needed to share were things like data set loaders for specification > tests for example. These are generic by nature and do not require any > dependencies, thus making isolation in a separate module pretty straight > forward. However for mocks ans stubs François's solution is more elegant > where you will use the assembly plugin and generate an extra jar packaging > all the test stuff together. all in all you will achieve the same end > result. However you must be careful here on what you share between > projects > as it is generally considered bad practice for unit tests to have > dependencies outside their domain. This being said recoding the same stub > every time you need to fake a class from another jar is just insane, > packaging mocks for the classes at the interface of the package within the > same project and packaging them as separate test jars sounds much better. > > This is where I was coming with the solution I proposed earlier, most of > my > modules are split in two, one with all the interfaces, factories access > and > such and will becomes the API, another for the implementation. APIs can > have dependencies with other APIs, Implementation will only have > dependencies to it's API and other APIs. The upside is that it forces me > to > think long and hard about what has to be shared, what service provides the > library, and how it is to be done. Natural corollary from this is that > the > test code that needs to be shared is quite easy to determine as other > projects will have dependency only on the API. This is how I get to > prevent > circular dependencies since the tests will have the dame dependency graph > as > the rest of the project. > > Downside is that the project becomes very large very fast (3 to one split > in > modules), and this is where François's proposal becomes interesting, Under > the same module project I could have it generate all three jars. Sounds a > bit extreme but since I adopted this Dependencies management through > dictatorship I found my advil consumption dropped dramatically, especially > when the interns that work here are warned that some medival torture > apparatus was rigged to their chairs and wired to the build, I then let > their imaginations connect the dots if the link with anything but API > packages. <evil gin> > > Anyhow, bit verbose but I hope it helped with your spinning head. ^_^. > > Sincerely, > > Éric :D. > > On 10/2/07, Awaragi <[EMAIL PROTECTED]> wrote: >> >> >> 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] >> >> > > -- View this message in context: http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a13002604 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
