I agree with a lot of this but I disagree that BDD is about testing your apps
behaviour only. BDD is about testing the behaviour of whatever is currently the
subject. Only testing the behaviour of the app would lead to solely writing
integration tests. There is plenty of behaviour in components, classes and
methods that need to be specified. Writing high level integration tests only,
leads to difficult to find bugs and often a slow running test suite. Small
changes in a class can break many integration tests since such tests are not
orthogonal, that was the core driver for TDD.
I personally use Remarkable as a simple way to have tests drive out my low
level implementation. I can't defend it within the BDD paradigm, which I
generally follow, but I feel more comfortable having a breaking test to drive
out my implementation. It is completely orthogonal and if the spec breaks I
know exactly why.
Cheers,
Adam
On 10/09/2011, at 5:44 PM, Ben Hoskings wrote:
> On 10/09/2011, at 5:06 PM, Brian Guthrie wrote:
>
>>> if you're doing proper BDD or TDD, a lot of unit tests are just unnecessary
>>
>> Could you maybe clarify this a bit? If you mean unit tests of private
>> methods, or avoiding overarchitecting (YAGNI), then I agree. But to me
>> testing the existence of associations certainly falls within the remit
>> of BDD--it's part of your class's public API, it's one of its
>> responsibilities, and to test it exercises the behavior of that class.
>
> To test it doesn't involve your app's behaviour. The only reason you create
> an association is to allow some other behaviour - it's not behaviour in and
> of itself.
>
> To check explicitly for the existence of an association isn't testing
> behaviour; it's testing that you remembered to write a line of code. You may
> as well also test you remembered to define the class. :)
>
> lambda { Artist }.should_not raise_error(NameError)
>
> As another example, to test your app's ability to hit some webservice, you
> should stub the webservice, and then test:
>
> -- That your app hits the API with the correct request
> -- That when provided with an expected (stubbed) response, your app handles
> it how you expect
>
> The idea is that your specs should stop exactly at the boundary between your
> code and the things it interacts with or is joined to -- whether the thing is
> a webservice, or a library like rails on top of which your app is built, or
> something else.
>
> - Ben
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-oceania@googlegroups.com.
> To unsubscribe from this group, send email to
> rails-oceania+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to rails-oceania@googlegroups.com.
To unsubscribe from this group, send email to
rails-oceania+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
