Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 33009 invoked from network); 16 Oct 2002 00:54:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Oct 2002 00:54:41 -0000 Received: (qmail 21918 invoked by uid 97); 16 Oct 2002 00:55:13 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 21785 invoked by uid 97); 16 Oct 2002 00:55:12 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 21612 invoked by uid 98); 16 Oct 2002 00:55:11 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Tue, 15 Oct 2002 17:54:19 -0700 (PDT) From: Tom Lipkis Message-Id: <200210160054.g9G0sJf19616@pss.com> To: ant-user@jakarta.apache.org In-reply-to: (message from Dominique Devienne on Tue, 15 Oct 2002 16:06:04 -0500) Subject: Re: Sorting filesets X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Perhaps... but unit tests should *all* run all the time. When you break > something, and indeed more than one test fail, go after the lower-level ones > first, and the other might go away as well. That's exactly what I'm trying to do. I want to run all the tests (well, most of the time), but if haltonfailure is on (which I prefer) it won't necessarily even get to the lower-level ones, and if it's off I have to search through the failures each time, mentally computing the component dependency graph. That's boring and repetitive, so I want to automate it. Ah, now I see that I should have phrased this not as wanting to sort the tests, but the test *failures*, so I can look at them in a sensible order. Would the XP crowd have considered that more acceptable? (Let's not get into the argument about whether I should often be causing lots of tests to fail. This came up when I made a large transformation to the code two days ago, now completed, and likely won't happen again soon.) > Sorting the unit tests is not > worth it IMHO. We used to do that, list explicitly the test methods to call, > and the test classes, to kind of do what you want, but kept on 'loosing' > tests. An automatic way to find test is much better. But that's just me! Me too. I don't want to maintain a list of tests to run; I want to run all of them using a fileset. As I encounter situations where I want one test to run before another, I can add prerequisites (too strong a word) to a static list in the latter file. These are used only to impose a partial ordering on the fileset list, so they're optional. Leaving them out doesn't cause tests not to run, and nothing is harmed if (when) they become obsolete. It's just a way to record my decisions about which failures I want to look at first. Tom -- To unsubscribe, e-mail: For additional commands, e-mail: