You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by bo...@apache.org on 2009/07/08 23:19:12 UTC
svn commit: r792325 - /buildr/trunk/doc/testing.textile
Author: boisvert
Date: Wed Jul 8 21:19:11 2009
New Revision: 792325
URL: http://svn.apache.org/viewvc?rev=792325&view=rev
Log:
Add example of test:*
Modified:
buildr/trunk/doc/testing.textile
Modified: buildr/trunk/doc/testing.textile
URL: http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?rev=792325&r1=792324&r2=792325&view=diff
==============================================================================
--- buildr/trunk/doc/testing.textile (original)
+++ buildr/trunk/doc/testing.textile Wed Jul 8 21:19:11 2009
@@ -92,6 +92,12 @@
$ buildr test:FooTest,BarTest
{% endhighlight %}
+Buildr forcefully runs all tests that match the pattern. If you want to re-run all tests even if your sources have not changed, you can execute:
+
+{% highlight sh %}
+$ buildr test:*
+{% endhighlight %}
+
As you probably noticed, Buildr will stop your build at the first test that fails. We think it's a good idea, except when it's not. If you're using a continuous build system, you'll want a report of all the failed tests without stopping at the first failure. To make that happen, set the environment variable @test@ to "all", or the Buildr @options.test@ option to @:all@. For example:
{% highlight sh %}
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Daniel Spiewak <dj...@gmail.com>.
I didn't realize that Rake handled the envar vs command-line invocation
automatically. That of course changes things. I'm still not happy with
using "test" as an environment variable, but I don't have a better solution
to offer.
Daniel
On Wed, Jul 8, 2009 at 9:09 PM, Assaf Arkin <as...@labnotes.org> wrote:
> On Wed, Jul 8, 2009 at 5:58 PM, Alex Boisvert <bo...@intalio.com>
> wrote:
>
> > On Wed, Jul 8, 2009 at 5:50 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > > > If it broke, I'll probably spend an hour of frustration before I
> catch
> > > why
> > > > my tests are not working as expected. On the other hand, buildr
> package
> > > > test=no vs buildr package build_test=no ... no contest. And I like
> > being
> > > > able to export test=no.
> > >
> > >
> > > I agree 100% that it should remain `buildr package test=no`. It would
> > > drive
> > > me batty if we changed that. However, I question whether export
> test=no
> > is
> > > really all that useful. Or, more importantly, I question whether
> `export
> > > BUILDR_TEST=no` is really all that inconvenient. To me at least, this
> > > looks
> > > a lot more representative of what it's doing (setting the TEST property
> > for
> > > the BUILDR tool). I don't think there would be any confusion if we had
> > > BUILDR_TEST for the envar and test for the invocation form,
> particularly
> > > since one is capitalized while the other is not (as per the Unix
> > > convention).
> >
> >
> > This would be my preference as well... with the caveat that variable
> > bindings passed on the command-line would be specific to Buildr and no
> > longer general environment variable equivalents. I understand it would
> > break from Rake conventions as well.
>
>
> That means duplicating the number of variables that control testing,
> complicating documentation, specs and code, creating one-off special case
> for that one variable, either writing spaghetti around rake's envvar
> handling, or duplicating code that already works.
>
> If we do that, should we be solving a real problem?
>
> This "problem" has been around since before 1.0, and I'm looking at the
> cost
> so far (of not having it fixed), versus the cost of having it fixed, and
> cold hard calculation says we should leave it alone.
>
> Assaf
>
> >
> >
> > alex
> >
>
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Assaf Arkin <as...@labnotes.org>.
On Wed, Jul 8, 2009 at 5:58 PM, Alex Boisvert <bo...@intalio.com> wrote:
> On Wed, Jul 8, 2009 at 5:50 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > > If it broke, I'll probably spend an hour of frustration before I catch
> > why
> > > my tests are not working as expected. On the other hand, buildr package
> > > test=no vs buildr package build_test=no ... no contest. And I like
> being
> > > able to export test=no.
> >
> >
> > I agree 100% that it should remain `buildr package test=no`. It would
> > drive
> > me batty if we changed that. However, I question whether export test=no
> is
> > really all that useful. Or, more importantly, I question whether `export
> > BUILDR_TEST=no` is really all that inconvenient. To me at least, this
> > looks
> > a lot more representative of what it's doing (setting the TEST property
> for
> > the BUILDR tool). I don't think there would be any confusion if we had
> > BUILDR_TEST for the envar and test for the invocation form, particularly
> > since one is capitalized while the other is not (as per the Unix
> > convention).
>
>
> This would be my preference as well... with the caveat that variable
> bindings passed on the command-line would be specific to Buildr and no
> longer general environment variable equivalents. I understand it would
> break from Rake conventions as well.
That means duplicating the number of variables that control testing,
complicating documentation, specs and code, creating one-off special case
for that one variable, either writing spaghetti around rake's envvar
handling, or duplicating code that already works.
If we do that, should we be solving a real problem?
This "problem" has been around since before 1.0, and I'm looking at the cost
so far (of not having it fixed), versus the cost of having it fixed, and
cold hard calculation says we should leave it alone.
Assaf
>
>
> alex
>
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Alex Boisvert <bo...@intalio.com>.
On Wed, Jul 8, 2009 at 5:50 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> > If it broke, I'll probably spend an hour of frustration before I catch
> why
> > my tests are not working as expected. On the other hand, buildr package
> > test=no vs buildr package build_test=no ... no contest. And I like being
> > able to export test=no.
>
>
> I agree 100% that it should remain `buildr package test=no`. It would
> drive
> me batty if we changed that. However, I question whether export test=no is
> really all that useful. Or, more importantly, I question whether `export
> BUILDR_TEST=no` is really all that inconvenient. To me at least, this
> looks
> a lot more representative of what it's doing (setting the TEST property for
> the BUILDR tool). I don't think there would be any confusion if we had
> BUILDR_TEST for the envar and test for the invocation form, particularly
> since one is capitalized while the other is not (as per the Unix
> convention).
This would be my preference as well... with the caveat that variable
bindings passed on the command-line would be specific to Buildr and no
longer general environment variable equivalents. I understand it would
break from Rake conventions as well.
alex
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Daniel Spiewak <dj...@gmail.com>.
> If it broke, I'll probably spend an hour of frustration before I catch why
> my tests are not working as expected. On the other hand, buildr package
> test=no vs buildr package build_test=no ... no contest. And I like being
> able to export test=no.
I agree 100% that it should remain `buildr package test=no`. It would drive
me batty if we changed that. However, I question whether export test=no is
really all that useful. Or, more importantly, I question whether `export
BUILDR_TEST=no` is really all that inconvenient. To me at least, this looks
a lot more representative of what it's doing (setting the TEST property for
the BUILDR tool). I don't think there would be any confusion if we had
BUILDR_TEST for the envar and test for the invocation form, particularly
since one is capitalized while the other is not (as per the Unix
convention).
> So I just applied probability of it breaking (x pain factor) vs persistent
> annoyance of avoiding breakage, and short form won.
In my opinion, you're underestimating the pain factor and overestimating the
persistent annoyance. That is just my opinion though.
Daniel
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Assaf Arkin <as...@labnotes.org>.
On Wed, Jul 8, 2009 at 5:17 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> It doesn't conflict with anything (that I know of). However, it's such a
> non-specific name to be putting in a global namespace. It just seems to me
> like a really bad practice.
If it broke, I'll probably spend an hour of frustration before I catch why
my tests are not working as expected. On the other hand, buildr package
test=no vs buildr package build_test=no ... no contest. And I like being
able to export test=no.
So I just applied probability of it breaking (x pain factor) vs persistent
annoyance of avoiding breakage, and short form won.
Assaf
>
>
> Daniel
>
> On Wed, Jul 8, 2009 at 6:18 PM, Assaf Arkin <as...@labnotes.org> wrote:
>
> > On Wed, Jul 8, 2009 at 2:25 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > > This says "environment variable" @test@. Does that mean that Buildr
> is
> > > checking for a shell variable named "test" ( ENV['test'] )? If so,
> > > shouldn't this be a less ambiguously named variable like BUILDR_TEST?
> >
> >
> > What does it conflict with?
> >
> > Assaf
> >
> >
> > >
> > >
> > > Daniel
> > >
> > >
> > > On Jul 8, 2009, at 4:19 PM, "boisvert@apache.org" <boisvert@apache.org
> >
> > > wrote:
> > >
> > > Author: boisvert
> > >> Date: Wed Jul 8 21:19:11 2009
> > >> New Revision: 792325
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=792325&view=rev
> > >> Log:
> > >> Add example of test:*
> > >>
> > >> Modified:
> > >> buildr/trunk/doc/testing.textile
> > >>
> > >> Modified: buildr/trunk/doc/testing.textile
> > >> URL:
> > >>
> >
> http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?rev=792325&r1=792324&r2=792325&view=diff
> > >>
> > >>
> >
> ==============================================================================
> > >> --- buildr/trunk/doc/testing.textile (original)
> > >> +++ buildr/trunk/doc/testing.textile Wed Jul 8 21:19:11 2009
> > >> @@ -92,6 +92,12 @@
> > >> $ buildr test:FooTest,BarTest
> > >> {% endhighlight %}
> > >>
> > >> +Buildr forcefully runs all tests that match the pattern. If you want
> > to
> > >> re-run all tests even if your sources have not changed, you can
> execute:
> > >> +
> > >> +{% highlight sh %}
> > >> +$ buildr test:*
> > >> +{% endhighlight %}
> > >> +
> > >> As you probably noticed, Buildr will stop your build at the first test
> > >> that fails. We think it's a good idea, except when it's not. If
> you're
> > >> using a continuous build system, you'll want a report of all the
> failed
> > >> tests without stopping at the first failure. To make that happen, set
> > the
> > >> environment variable @test@ to "all", or the Buildr
> @options.test@option
> > >> to @:all@. For example:
> > >>
> > >> {% highlight sh %}
> > >>
> > >>
> > >>
> >
>
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Daniel Spiewak <dj...@gmail.com>.
It doesn't conflict with anything (that I know of). However, it's such a
non-specific name to be putting in a global namespace. It just seems to me
like a really bad practice.
Daniel
On Wed, Jul 8, 2009 at 6:18 PM, Assaf Arkin <as...@labnotes.org> wrote:
> On Wed, Jul 8, 2009 at 2:25 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > This says "environment variable" @test@. Does that mean that Buildr is
> > checking for a shell variable named "test" ( ENV['test'] )? If so,
> > shouldn't this be a less ambiguously named variable like BUILDR_TEST?
>
>
> What does it conflict with?
>
> Assaf
>
>
> >
> >
> > Daniel
> >
> >
> > On Jul 8, 2009, at 4:19 PM, "boisvert@apache.org" <bo...@apache.org>
> > wrote:
> >
> > Author: boisvert
> >> Date: Wed Jul 8 21:19:11 2009
> >> New Revision: 792325
> >>
> >> URL: http://svn.apache.org/viewvc?rev=792325&view=rev
> >> Log:
> >> Add example of test:*
> >>
> >> Modified:
> >> buildr/trunk/doc/testing.textile
> >>
> >> Modified: buildr/trunk/doc/testing.textile
> >> URL:
> >>
> http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?rev=792325&r1=792324&r2=792325&view=diff
> >>
> >>
> ==============================================================================
> >> --- buildr/trunk/doc/testing.textile (original)
> >> +++ buildr/trunk/doc/testing.textile Wed Jul 8 21:19:11 2009
> >> @@ -92,6 +92,12 @@
> >> $ buildr test:FooTest,BarTest
> >> {% endhighlight %}
> >>
> >> +Buildr forcefully runs all tests that match the pattern. If you want
> to
> >> re-run all tests even if your sources have not changed, you can execute:
> >> +
> >> +{% highlight sh %}
> >> +$ buildr test:*
> >> +{% endhighlight %}
> >> +
> >> As you probably noticed, Buildr will stop your build at the first test
> >> that fails. We think it's a good idea, except when it's not. If you're
> >> using a continuous build system, you'll want a report of all the failed
> >> tests without stopping at the first failure. To make that happen, set
> the
> >> environment variable @test@ to "all", or the Buildr @options.test@option
> >> to @:all@. For example:
> >>
> >> {% highlight sh %}
> >>
> >>
> >>
>
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Assaf Arkin <as...@labnotes.org>.
On Wed, Jul 8, 2009 at 2:25 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> This says "environment variable" @test@. Does that mean that Buildr is
> checking for a shell variable named "test" ( ENV['test'] )? If so,
> shouldn't this be a less ambiguously named variable like BUILDR_TEST?
What does it conflict with?
Assaf
>
>
> Daniel
>
>
> On Jul 8, 2009, at 4:19 PM, "boisvert@apache.org" <bo...@apache.org>
> wrote:
>
> Author: boisvert
>> Date: Wed Jul 8 21:19:11 2009
>> New Revision: 792325
>>
>> URL: http://svn.apache.org/viewvc?rev=792325&view=rev
>> Log:
>> Add example of test:*
>>
>> Modified:
>> buildr/trunk/doc/testing.textile
>>
>> Modified: buildr/trunk/doc/testing.textile
>> URL:
>> http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?rev=792325&r1=792324&r2=792325&view=diff
>>
>> ==============================================================================
>> --- buildr/trunk/doc/testing.textile (original)
>> +++ buildr/trunk/doc/testing.textile Wed Jul 8 21:19:11 2009
>> @@ -92,6 +92,12 @@
>> $ buildr test:FooTest,BarTest
>> {% endhighlight %}
>>
>> +Buildr forcefully runs all tests that match the pattern. If you want to
>> re-run all tests even if your sources have not changed, you can execute:
>> +
>> +{% highlight sh %}
>> +$ buildr test:*
>> +{% endhighlight %}
>> +
>> As you probably noticed, Buildr will stop your build at the first test
>> that fails. We think it's a good idea, except when it's not. If you're
>> using a continuous build system, you'll want a report of all the failed
>> tests without stopping at the first failure. To make that happen, set the
>> environment variable @test@ to "all", or the Buildr @options.test@ option
>> to @:all@. For example:
>>
>> {% highlight sh %}
>>
>>
>>
Re: svn commit: r792325 - /buildr/trunk/doc/testing.textile
Posted by Daniel Spiewak <dj...@gmail.com>.
This says "environment variable" @test@. Does that mean that Buildr
is checking for a shell variable named "test" ( ENV['test'] )? If so,
shouldn't this be a less ambiguously named variable like BUILDR_TEST?
Daniel
On Jul 8, 2009, at 4:19 PM, "boisvert@apache.org"
<bo...@apache.org> wrote:
> Author: boisvert
> Date: Wed Jul 8 21:19:11 2009
> New Revision: 792325
>
> URL: http://svn.apache.org/viewvc?rev=792325&view=rev
> Log:
> Add example of test:*
>
> Modified:
> buildr/trunk/doc/testing.textile
>
> Modified: buildr/trunk/doc/testing.textile
> URL: http://svn.apache.org/viewvc/buildr/trunk/doc/testing.textile?rev=792325&r1=792324&r2=792325&view=diff
> ===
> ===
> ===
> =====================================================================
> --- buildr/trunk/doc/testing.textile (original)
> +++ buildr/trunk/doc/testing.textile Wed Jul 8 21:19:11 2009
> @@ -92,6 +92,12 @@
> $ buildr test:FooTest,BarTest
> {% endhighlight %}
>
> +Buildr forcefully runs all tests that match the pattern. If you
> want to re-run all tests even if your sources have not changed, you
> can execute:
> +
> +{% highlight sh %}
> +$ buildr test:*
> +{% endhighlight %}
> +
> As you probably noticed, Buildr will stop your build at the first
> test that fails. We think it's a good idea, except when it's not.
> If you're using a continuous build system, you'll want a report of
> all the failed tests without stopping at the first failure. To make
> that happen, set the environment variable @test@ to "all", or the
> Buildr @options.test@ option to @:all@. For example:
>
> {% highlight sh %}
>
>