Sorry Stu, we've kind of dragged this into more high level philosophical 
territory here than your original question. :D

Adam,

On 10/09/2011, at 6:32 PM, Adam Boas wrote:

> 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.

Just to clarify, I didn't advocate writing high level tests only. In the 
interests of being explicit, what I'm advocating (I can't speak for Ben 
obviously) is starting at the app behaviour, and working your way in. Write an 
integration test, decide how to implement that, then write functional/unit 
specs to drive the code you write. Get the unit specs to pass, then the func 
specs, then the integrations. Rinse, repeat. At no point in that process would 
I feel the need to test a has_many association was working as it should - I 
trust the rails tests to have already done that.

> 
> 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.
> 

In a larger project, I could definitely see the advantage in having a bunch of 
sanity checks as far as the existence of certain associations, etc, and in fact 
have done something similar in the past.

Cheers,

Warren.

-- 
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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Reply via email to