No mocks, the tests populate databases in a transactional manner. Validation is performed in the database layer as well so a mock object would not be able to test the data.
On Fri, Nov 29, 2013 at 11:05 AM, Tjeerd Verhagen <tjeerd.verha...@gmail.com > wrote: > Are there no Mock objects used, for these tests? Like a Invoice mock > instance, in the Customer tests? And a Customer Mock instance, for the > Invoice tests? > > > On Fri, Nov 29, 2013 at 6:54 PM, Steve Heyns <notzi...@gmail.com> wrote: > > > Lol, thanks - unfortunately I was not the one who created the mess, just > > the one left to fix it. (and yes there are already modules c,d,e,f as > > well). My gut told me this was a bad situation but I just wanted to > confirm > > that there was no alternate solutions other then rebuilding the test > cases. > > > > There is no common framework, just reused objects for instance, one > module > > is an customer module and another is a invoice module. The invoice test > > module uses the customers test cases to create a new test customer (for > the > > invoice). The customer module uses the invoice module to create an > invoice > > and test that the customer cannot be deactivated with an active invoice. > So > > the easy fix would be is to move the customer deactivate test to the > > invoice side. Is that the only way to fix ? Or is there something better > ? > > > > thx > > Nz > > > > > > On Fri, Nov 29, 2013 at 9:21 AM, Eyad Ebrahim <tya...@gmail.com> wrote: > > > > > Out of a similar experience. Analyse the dependency and break it. > Module > > C > > > is due > > > On Nov 29, 2013 6:10 PM, "Tjeerd Verhagen" <tjeerd.verha...@gmail.com> > > > wrote: > > > > > > > Hello, > > > > > > > > It is never good to have recursive dependencies. So think of a way to > > get > > > > these out off the way. And especially in test jars, they should never > > > > depend up on other test jars. In case you have some supporting > classes, > > > > which are only used in test jars, create a normal jar, similar like > the > > > > spring-test-util jar. It is a test cases helper jar, but not a jar > > which > > > > contains tests. > > > > > > > > Hope this helps. > > > > > > > > Kind regards, Tjeerd > > > > > > > > > > > > On Fri, Nov 29, 2013 at 5:56 PM, Steve Heyns <notzi...@gmail.com> > > wrote: > > > > > > > > > Hi > > > > > > > > > > I am trying to migrate 2 build scripts to use ivy, they are 2 > > separate > > > > > modules. What I want to publish is > > > > > > > > > > module a.jar (conf main) > > > > > module a test.jar (conf test) > > > > > > > > > > module b.jar (conf main) > > > > > module b test.jar (conf test) > > > > > > > > > > Issue is that module a test depends on module b, and module b test > > > > depends > > > > > on module a. The current way to build is to compile module a, then > > > > module b > > > > > then module a test, the module b test. To replicate this using ivy > I > > > > would > > > > > need to be able to publish the source from both modules without the > > > test > > > > > artifact, then publish the test artifacts. From what I understand > > > > > publishing only one artifact is not possible with ivy. But it seems > > odd > > > > to > > > > > define separate ivy files. Anyone with ideas > > > > > > > > > > > thanks > > > > > Nz > > > > > > > > > > > > > > >
