Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

63 lines (46 sloc) 2.205 kb
Reading Specs
=============
Blah blah blah...
Writing Specs
=============
Here are some general dos and don'ts
= DO:
* Write more specs for error conditions than clean conditions.
* Write specs with readability in mind. Somebody knew to DataMapper should be
able to read specs to learn how something works.
* Use existing models that are part of a metaphor.
* Nest describe blocks (2 or 3 levels deep is probably fine).
* Limit a describe block to 10 - 15 examples.
* Group specs by method being tested. (See the 'Ordering Specs' section)
* Use custom matchers.
= DON'T:
* Spec more than one unit of functionality in an example. An example should be
as short as possible (while still remaining readable).
* Spec implementation. Refactoring code should not break specs.
* Declare models in the spec file.
And a final do: Do go against the guidelines if your best judgement tells you
to. These are just guidelines and are obviously not fast rules.
Models
======
Models are declared in separate files as opposed to individual spec files for
two reasons. The first is to improve readability. By creating as few models
as possible and sharing these models throughout the specs, a reader can
become familiar with the models being used quicker. Models also follow a
few simple metaphors, such as a zoo, a blog implementation, etc... Following
metaphors makes it easier for a reader to guess what is going on with respect
to the models.
The second reason is to allow the spec environment to be as pristine as
possible going into an example. Models being loaded from the model directory
are tracked and reloaded before each example. Any changes that might be made
to the model are reset at the end.
Mocks and Stubs
===============
Obviously, mocks and stubs are a powerful feature when it comes to BDD;
however, remember that you are writing specs for behavior and NOT
implementation.
Ordering Specs
==============
Specs aren't much use if nobody can find where anything is, so keeping specs
well organized is critical. Currently, we are trying out the following
structure:
* List guidelines here...
Jump to Line
Something went wrong with that request. Please try again.