buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: [buildr] Compile and test order
Date Fri, 15 Aug 2008 21:29:17 GMT
On Fri, Aug 15, 2008 at 1:56 PM, lacton <> wrote:
> On Fri, Aug 15, 2008 at 8:37 PM, Assaf Arkin <> wrote:
>> If we can get tests to run when necessary, and only when necessary,
>> score a big win.  You get tests to check what you're doing, but
>> without slowing you down.  My concern is that if we run tests
>> unnecessarily, people will just learn to tune them off, so we need to
>> be conservative with the tests we run.
> Agreed.
> Running tests whenever there's a chance they could fail.  Not running
> them when there is absolutely no value in doing it.
>> Right now the test task is not smart enough to do that, I'd like to
>> see a way for foo:test to only run if something changed. So that
>> would be the first problem to solve.
> Yes. I'm toying with a TestTask that has a custom 'needed?' method
> that checks timestamps.
> The algorithm I use is: a test run is needed if and only if there one
> or more test dependencies with a timestamp later than the time of the
> last successful test run for this project.

That would most probably work for what we have right now.  Compile and
resources both touch their target when they're done running, so if the
target is newer, something interesting happened.  And test depends on

My only worry is trying to identify all the things that would not work
as expected.  For example, if you change the dependencies you use
(compile.with, test.with, etc) nothing interesting happens.  Tests
don't run even though they should.  Easy to fix by adding buildfile as
a prerequisite (the IDE tasks do just that).  What else could we be

> From an implementation point of view, I store the last successful test
> run time on the file system by touching a 'last_successful_run' file
> in the test.report_to directory when a test run succeeds.
> What do you think of this idea?

Sounds good.

>> But we also need a way to force
>> all tests to run, especially when you're doing things like coverage
>> reports or cutting a release.  Ideas?
> The simplest thing I can imagine is to do exactly what one would do to
> force all classes to be compiled or packaged.  Call 'buildr clean'.

Maybe test=force to always report needed? as true?


> Lacton
>> Assaf

View raw message