Return-Path: Delivered-To: apmail-db-torque-user-archive@db.apache.org Received: (qmail 53284 invoked by uid 500); 18 Aug 2003 13:25:57 -0000 Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Apache Torque Users List" Reply-To: "Apache Torque Users List" Delivered-To: mailing list torque-user@db.apache.org Received: (qmail 53273 invoked from network); 18 Aug 2003 13:25:56 -0000 Received: from ms-smtp-02.rdc-kc.rr.com (24.94.166.122) by daedalus.apache.org with SMTP; 18 Aug 2003 13:25:56 -0000 Received: from firefoot (CPE-24-211-19-232.wi.rr.com [24.211.19.232]) by ms-smtp-02.rdc-kc.rr.com (8.12.8p1/8.12.7) with ESMTP id h7IDPtKX011578; Mon, 18 Aug 2003 08:25:56 -0500 (CDT) Received: from jbrekke by firefoot with local (Exim 3.36 #1 (Debian)) id 19ojqY-0002eH-00; Mon, 18 Aug 2003 08:14:54 -0500 To: Apache Torque Users List Cc: mbe@lucka.nl Subject: Re: unit testing code using torque References: <24895.195.18.91.28.1061193830.squirrel@webmail.xs4all.nl> From: jbrekke@wi.rr.com (Jeffrey D. Brekke) Date: Mon, 18 Aug 2003 08:14:54 -0500 In-Reply-To: <24895.195.18.91.28.1061193830.squirrel@webmail.xs4all.nl> (Michel Beijlevelt's message of "Mon, 18 Aug 2003 10:03:50 +0200 (CEST)") Message-ID: <85wudbqf8x.fsf@wi.rr.com> User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Jeffrey D. Brekke" X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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. Michel Beijlevelt writes: > Hi all, > > interesting discussion, as I'm pondering JUnit tests for my Torque based > project at this moment as well. I don't feel comfortable providing mock > objects in place because one might introduce errors that don't exist in > Torque, skip errors in Torque that are circumvented by the mock objects, > and it would be a lot of work too. > > Currently we have some factories that create and maintain the Torque > database connection and we're working on some factories that create (and > destroy) test data through Torque which will be called from the setup and > teardown methods from the testsuites. Sure, this is slow but I'm very > willing to sacrifice this for better tests and ultimately better code. > > We don't test the Torque functionality itself btw (apart from some Peer > extensions). > > Hopefully this thread has a longlife, I'm very curious for soltions from > others. > > BTW, does any one know if it's needed to save() all modifications that are > made to torque-based objects? As long as the objects aren't destroyed, > the data should remain in cache, right? Yes, this is how we do our programmer tests, skipping the save() altogether. I haven't used the caching though, the objects for sure will continue to hold the data. They're just pojo's at this point. > gr. Michel > > > > David Hainlin wrote: > >> Hi Gary, >> I've done a fair amount of JUnit testing around Torque based projects. > Except in a few specialized classes, I've never found the need to > provide mock torque classes as most of the OM and business related code > really does depend on data Torque is fetching for me. Most of my Torque > Peer extensions have been very straightforward. This type of approach > does require some careful DB planning, and a 'resettable' test database. > Most of my unit tests that work from different levels (say struts mock > objects) either back out any db changes or invoke a 'set up test db' > script. This keeps everything repeatable. On a larger project with > many developers, we had the good fortune to own all of the schema. The > deployment was Oracle but I tested using mySQL with pretty good success. > On projects with less db control and with many developers running unit > tests, I've resorted to id ranging (David gets 1000 through 10000, > Ramesh gets 10000 through 20000, etc...). If you plan ahead, you can > set your 'production' or 'integrated' torque id generation to start > above these levels. >> >> I'm curious about your thoughts on this I'd be interested in hearing > about your experiences. >> >> David > > > > > --------------------------------------------------------------------- > 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