ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Heyns <notzi...@gmail.com>
Subject Re: Question about module builds
Date Fri, 29 Nov 2013 19:25:37 GMT
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.verhagen@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 <notzippy@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 <tyados@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.verhagen@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 <notzippy@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
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message