@@ -1,7 +1,7 @@ = Quick Links * Setup and Configuration - DataMapper -* Finders and CRUD - +* Finders and CRUD - * Properties - DataMapper::Property * FAQ[link:/files/FAQ.html] * Contact Us @@ -9,4 +9,3 @@ * Bug Reports - http://wm.lighthouseapp.com/projects/4819-datamapper/overview * IRC Channel - <tt>##datamapper</tt> on irc.freenode.net * Mailing List - http://groups.google.com/group/datamapper/ - QUICKLINKS @@ -2,14 +2,14 @@ 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. @@ -18,14 +18,14 @@ Writing Specs * 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. @@ -39,7 +39,7 @@ Models 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 @@ -51,13 +51,12 @@ 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... - \ No newline at end of file SPECS a413f73d744749e24b2ac3d8a1028f14d47297b7 Dan Kubb dan.kubb@autopilotmarketing.com http://github.com/sam/dm-core/commit/d52ade574dadd45f278dc84fcc59e975cfb97821 d52ade574dadd45f278dc84fcc59e975cfb97821

2008-11-29T23:25:37-08:00

Stripped whitespace 9e412fa633337dde61d03f2324d57d3f9855442e Dan Kubb dan.kubb@autopilotmarketing.com