db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: unit testing code using torque
Date Mon, 18 Aug 2003 15:23:23 GMT


Michel Beijlevelt / Lucka <mbe@lucka.nl> writes:

> I must admit I'm not sure what you're trying to say.
>
> Are you saying that our JUnit tests shouldn't include testing Torque
> functionality ?
>
> Well, they don't. We're not testing Torque-logic itself.
>
> But the (business) logic we're testing is dependent on certain
> database circumstances that we create using Torque during the tests,
> and is using Torque as part of the business logic. In this scenario
> I'd don't like to use mock objects instead of  real Torque objects
> because when the application will be running in real life, it will be
> using the Torque objects as well, and thus I want to be sure that my
> application together with Torque is running as expected. Anyway,
> that's what I was trying to say in my previous mail.

I agree and don't use Mocks unless I'm really in a pinch.  Torque
generated objects are actually pretty good at behaving like pojo's if
you stay away from save().

> For example, if want to test if creating a Contract fails when there
> already is another Contract active, I first create an active Contract
> (using Torque logic underneath) , then create another Contract (using
> Torque logic underneath)  and assert the second creation failed.

I guess I look at the situation as I don't want my tests to depend on
external systems at all.  So I don't want to hit the database every time.
If I am comfortable that torque is written well, I don't need to test
that the generated code will fail on the second assertion by going all
the way to the db.  There should be tests in the torque project that
verify that it works right.

Now if I want to test how my code behaves when a Contract fails to be
created since it already exists, I am testing my code and can use
torque obejcts without mocks to do that and still not hit the
database.  Or maybe we want to make sure that the schema is correctly
defining a unique attribute on a column or something.

I don't mean to confuse the issue and agree that this is a very
interesting topic.  I've seen our tests get slow and off target when
we don't think about what it is we are testing and what dependencies
are required to run the tests.  I am proceeding under the goal that
programmer tests will be fast and test code that we wrote.  Generally I
have a few tests that do excersise torque all the way to the db, but
only a small few.  The rest I don't want to hit the db and proceed
that torque is correctly implemented.

> gr. Michel
>
>
>
> Jeffrey D. Brekke wrote:
>
>> Sounds like your testing factory should be in the torque project,
>> testing itself.  If you are comfortable that torque doesn't have any
>> errors, then maybe
>>we wouldn't feel like we have to test access through torque to the db
>>in all our application tests.  Unless you are also really testing
>>things other than your code.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message