Phlip
2/1/2009 12:41:00 PM
Christian Neukirchen wrote:
> In test/spec, it looks like this:
>
> require 'test/spec'
>
> context "Foo" do
> specify "should bar" do
> (2 + 3).should.equal 5
> end
> end
We use TextMate at work. (This may come as a surprise to those of you who read
my posts, but I lack the political prowess to help us move to Aptana or
something with a better GUI...)
When we put a cursor inside a def test_case and claw <Shift+Splat+R>, TextMate
finds the 'def test_case' above us, and runs ruby -n file_name/test_case.
That gives us Incremental Testing during our Test-Driven Development sessions.
We auditioned test/spec, and we have many specs still in producton, but we found
that <Shift+Splat+R> did not always work. Sometimes it runs the right spec, and
sometimes the wrong one...
I'm aware this is not your fault, but I remain curious about our editors'
general abilities to help and not hinder TDD!
Now a question about spec architecture in general.
> context "Numbers"
> class EqualString < Test::Spec::CustomShould
> def matches?(other)
> object == other.to_s
> end
> end
>
> def equal_string(str)
> EqualString.new(str)
> end
>
> specify "should have to_s"
> 42.should equal_string("42")
> end
> end
As far as I can tell, the only aspect of any *spec system that is not just a
remap of test_case architecture is the ability to run nested context{} blocks
with incrementally nested setup{} blocks.
context 'foo' do
setup{ @foo = Foo.new }
it('should see foo'){ @foo.should.not.be.nil }
def increment_foo
return @foo.x + 42
end
context 'foo' do
setup{ @bar = Bar.new }
it 'should see both foo & bar' do
@foo.should.not.be.nil
@bar.should.not.be.nil
end
end
end
That is very important for projects with lots of business rules.
However, can the inner context see the method increment_foo() ?
--
Phlip