[rspec-users] Assumption tests

Scott Taylor mailing_lists at railsnewbie.com
Sat Oct 20 00:34:56 EDT 2007

On Oct 19, 2007, at 12:29 PM, Pat Maddox wrote:

> On 10/19/07, Daniel Tenner <daniel.ruby at tenner.org> wrote:
>>> If I read correctly, Daniel is suggesting that this is not behaviour
>>> because he's equating behaviour with interaction. This example  
>>> checks
>>> an outcome, not an interaction.
>> That's right, one of my axioms is that "specifying" involves
>> behaviour/interaction, not state/outcome.
> To be honest, I think you're way off the mark.  Objects behave in two
> ways: they manipulate their state, or they interact with other
> objects.  Both are valid types of behavior and can be used for
> specification.


> Calling withdraw doesn't reduce the account balance.  It reduces the
> balance reported by the account.  It's a subtle distinction, and one
> that's not important to think about 99% of the time.  Hopefully though
> you see why it's a fallacy to discount state-based testing as a valid
> specification technique.  As long as you're using an object's API, and
> not digging into it's internal state as in David's evil example,
> you're dealing with behavior.

Couldn't agree with Pat more.

As I see it, the problem is that ActiveRecord is not like a typical  
library, which is completely external.  With rails,  
ActiveRecord::Base (and co) *become* your code.  This should be  
obvious from the fact that you are decending from a base class which  
can never be instantiated.  Maybe this is how you got on to the whole  
*assumption* test in the first place?

Of course, if you wanted to split up your specs into specs/, stories/  
and assumptions/, you would certainly be free to.

Following up on the last idea: One thing that I don't think is yet  
widely understood is that there is no such thing as a "unit" or  
"integration" test - test happen on a continuum (the classification  
of a test is not a black and white sort of thing).  Your "assumption  
tests" are basically model-level integration tests, which are not as  
fine grained as the normal spec (which would mock/stub out AR::Base,  
associations, validations (with load...), etc).


More information about the rspec-users mailing list