ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <lmead...@apache.org>
Subject Re: Build Time Checks
Date Sun, 15 Jan 2006 21:45:41 GMT
I have used dbUnit to do unit testing against the real database that
my application used because of the use of triggers and stored
procedures.

It worked pretty well, but setting up a full-on mock dataset with XML
can be a bit intimidating.

It does allow exporting data, which helps quite a bit.

Larry


On 1/14/06, Gregg D Bolinger <gthought@gmail.com> wrote:
> Derby (which is an Apache project now) has an in memory mode.  At any rate,
> yes, the quoted text was not stated correctly.  I'll try again.
>
> Is it common/good practise to perform unit tests that actually hit a
> database versus using mock objects?  Should I be doing both?
>
> Ok, probably not an iBatis mailing list question, but....
>
> Thanks.
>
>
> Gregg
>
> On 1/14/06, Clinton Begin < clinton.begin@gmail.com> wrote:
> > I think your quoted question is missing a word or something. :-)
> >
> > In any case, I recommend HSQLDB over Derby if you have a choice, only
> because HSQLDB will be much faster, as it has an "in memory" mode.
> >
> > When I tried to port the iBATIS unit tests to Derby, the build took like
> 10 times longer. (not a problem with derby, just the reality of physical
> disks vs. DDR -- for what it's worth, I think Derby is a better "real"
> database).
> >
> >
> > Cheers,
> > Clinton
> >
> >
> > On 1/14/06, Gregg D Bolinger < gthought@gmail.com> wrote:
> > >
> > > Thanks Clinton.  I suppose I could do something similar with Derby.  I
> guess my question was a more general "Is it ok to do unit tests that
> actually unit tests?"  Or rather, is it common practice?
> > >
> > >
> > > Gregg
> > >
> > >
> > > On 1/14/06, Clinton Begin <clinton.begin@gmail.com > wrote:
> > > >
> > > > I use HSQLDB for my ibatis unit tests.  It's totally effective for
> most well written SQL.  Only SQL that uses custom functions or stored procs
> will require your real database.  In such cases, we (where I work) give each
> developer their own account on the database server, or a copy of the
> database on their local machine (depending on the practicality of the
> database).
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 1/14/06, Gregg D Bolinger <gthought@gmail.com > wrote:
> > > > >
> > > > > I do unit tests.  I've heard good and bad about performing unit
> tests that actually hit the database.  Typical scenerio is to use Mock
> Objects so you don't have too.  Anyone care to elaborate on unit testing
> that actually hits the database?
> > > > >
> > > > > Gregg
> > > > >
> > > > >
> > > > > On 1/14/06, Clinton Begin <clinton.begin@gmail.com > wrote:
> > > > > >
> > > > > > +1
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 1/14/06, Hycel Taylor <hycel1@gmail.com> wrote:
> > > > > > > Unit Tests.
> > > > > > >
> > > > > > > On 1/13/06, Gregg D Bolinger < gthought@gmail.com>
wrote:
> > > > > > > > I am looking for a way that I can validate my mapping
files
> against my
> > > > > > > > associated object files and even possibly the database.
> Basically, I want
> > > > > > > > to ensure that when the project it built, I run into
as few
> runtime issues
> > > > > > > > as possible.  As it is, if someone changes the database
or
> someone changed
> > > > > > > > an Object file or someone changed a mapping file,
I won't
> really know about
> > > > > > > > it until the app is deployed and running.
> > > > > > > >
> > > > > > > > I'd like to hear some stories and information on how
anyone
> else delt with
> > > > > > > > this problem, if at all.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Gregg
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Mime
View raw message