David Chelimsky-2 wrote:
>
>
> It depends on how high you have your magnifying glass set. Really!
>
> Here's how I'd get there:
>
> In an integration test, which I use as ... well ... integration tests
> (i.e. pretty close to end to end - just no browser, so the javascript
> can't get tested), I'd have something akin to the second example,
> except that the creates would be done through a controller. This would
> be in place before I ever started working on individual objects.
>
> Then I'd develop the view, followed by the controller, followed by the
> model. Typically, in my experience, that would result in something
> like (not executing these so please pardon any potential bugs):
>
> describe "/widgets/index" do
> it "should display a list of widgets" do
> assigns[:widgets] = [
> mock_model(Widget, :name => 'foo'),
> mock_model(Widget, :name => 'bar')
> ]
> render '/widgets/index'
> response.should have_tag('ul') do
> with_tag('li', 'foo')
> with_tag('li', 'bar')
> end
> end
> end
>
> describe WidgetController, 'responding to GET /widgets' do
> it "should assign a list of widgets" do
> Widget.should_receive(:find_alphabetically).and_return(list = [])
> get :index
> assigns[:widgets].should == []
> end
> end
>
> describe Widget, "class" do
> it "should provide a list of widgets sorted alphabetically" do
> Widget.should_receive(:find).with(:order => "name ASC")
> Widget.find_alphabetically
> end
> end
>
> You're correct that the refactoring requires you to change the
> object-level examples, and that is something that would be nice to
> avoid. But also keep in mind that in java and C# people refactor
> things like that all the time without batting an eye, because the
> tools make it a one-step activity. Refactoring is changing the design
> of your *system* without changing its behaviour. That doesn't really
> fly all the way down to the object level 100% of the time.
>
> WDYT?
>
> David
>
after reading your post yesterday, I dug out some old specs that were doing
some really complex setup using real objects, and rewrote them to
exclusively use mocks and stubs. The specs run around 20% quicker, but more
importantly, the code is much less complex and much easier to work with!
it's a relief not having to worry about model behaviour in controller specs.
so much so that I ended up adding around 50% more examples and catching some
bugs which I'd missed.
I wasn't testing my views at all, instead relying on integrate_views to
catch any problems. This time round I wrote view specs, which is a little
more work but testing only one MVC aspect in isolation really makes things
simpler. I realise now that the old way, I was using controller specs to
test integration rather than controllers.
I'm relatively new to programming, and it's all self taught so I can't speak
with authority, but the more I use BDD, the more I like it. It just makes
sense. thanks for your help
p.s. when is the book coming? :)
--
View this message in context:
http://www.nabble.com/testing-behaviour-or-testing-code--tf4322619.html#a12323713
Sent from the rspec-users mailing list archive at Nabble.com.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
