You can put expectations in your before block, and that'll give you
the behavior you want.

before(:each) do
   @org_root_prop = java.lang.System.getProperty("root")

   @org_root_prop.should_not be_nil
   @org_root_prop.trim.should_not be_empty
end

If either of those expectations fail then the examples that require
that property will report failures.  If I were using this all over the
place, I would write a custom matcher.

before(:each) do
  java.lang.System.should have_property("root")
  @org_root_prop = java.lang.System.getProperty("root")
end

This would allow you to define your own error message and perform more
sophisticated expectations (see the have_tag/with_tag example in
rspec-rails).

Note that you should be doing this check in before(:each) because you
want it to run before each example.  Also you should be using
before(:each) 99% of the time anyway.

Pat

On Mon, Jun 1, 2009 at 4:12 AM, mortench <morte...@gmail.com> wrote:
> Hi David,
>
> Thanks for the suggestion! It indeed make sense for the Junit
> example... However, my particular usage case for assumption is a bit
> different. I am using jruby+jspec and I have a group of rspec examples
> that all require a java property to be set for the examples to be able
> to run. Besides, the examples also have an after action that will also
> break if the java propety is not set. Idealy, I would like to do
> something like.
>
> before(:all) do
>   �...@org_root_prop = java.lang.System.getProperty("root")
>
>    # abort all examples and after action if condition is not meet:
>    ensure_that !rootPath.nil? && rootPath.strip.length>0
> end
>
> Notice, that the assume is in a before action and not in the examples
> themselves + it should affect the examples and after action (none of
> which should run if before action assumptions are not meet).
>
> /Morten
>
>
> On Jun 1, 12:58 pm, David Chelimsky <dchelim...@gmail.com> wrote:
>> On Mon, Jun 1, 2009 at 5:33 AM, mortench <morte...@gmail.com> wrote:
>> > JUnit 4.4+ has a feature called assumptions and I am looking for
>> > something similar in rspec so that I can express that my examples
>> > require a specific environment variable to be specified for testing to
>> > make sense.
>>
>> There is no explicit support for this, but you could always just say
>> (taking the example from the page you cited):
>>
>> def assume_that(expression)
>>   yield if expression
>> end
>>
>> def verify_that(actual, expected)
>>   actual.should expected
>> end
>>
>> it "should blah de blah" do
>>   assume_that(File::SEPARATOR == "/") do
>>     ensure_that User.new("optimus"), eql("configfiles/optimus.cfg")
>>   end
>> end
>>
>> I am planning to add support for something like ensure_that (name up
>> for grabs) in a future version of rspec, but I'd need to think about
>> assume_that a bit. We're dealing with Ruby here, not Java, and we
>> don't suffer things like a 'final' keyword that force us to have to
>> make assumptions like this. Unless we add some additional feedback,
>> like "such and such example did not run due to faulty assumptions,"
>> this seems quite dangerous to me. And even with that, it means that CI
>> servers are going to pass examples that are never actually run.
>>
>> HTH,
>> David
>>
>>
>>
>>
>>
>> > About assumptions from the readme (http://junit.sourceforge.net/doc/
>> > ReleaseNotes4.4.html#assumptions):
>> > "Ideally, the developer writing a test has control of all of the
>> > forces that might cause a test to fail. If this isn't immediately
>> > possible, making dependencies explicit can often improve a design.
>> > For example, if a test fails when run in a different locale than the
>> > developer intended, it can be fixed by explicitly passing a locale to
>> > the domain code.
>>
>> > However, sometimes this is not desirable or possible.
>> > It's good to be able to run a test against the code as it is currently
>> > written, implicit assumptions and all, or to write a test that exposes
>> > a known bug. For these situations, JUnit now includes the ability to
>> > express "assumptions":
>> > "
>>
>> > /Morten
>> > _______________________________________________
>> > rspec-users mailing list
>> > rspec-us...@rubyforge.org
>> >http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to