On Wed, Jan 30, 2013 at 10:06 AM, Myron Marston <[email protected]>wrote:
> On Jan 30, 12:33 am, [email protected] wrote: > > Awesome answer. > > I have being testing the Given/When/Then framework but the Then prints > out > > very ugly so I do not think I will use it. > > > > Your solution is good, I thought that doing several expectations inside > an > > 'it' was considered bad style. > > But I think I understand the general idea, what I really want to check is > > the fact that it has only one page and this high level check can be > > decomposed on these small checks in this case. > > > > Thank you very much. > > I believe the "one expectation per example" (or "one assertion per > test") guideline was born as a reaction to a testing style that would > pile up many unrelated assertions/expectations in a single test/ > example, which made it hard to understand what behavior was failing > when you get failure output. Separate from whether the expectations are related, the guideline is about understanding context. If 4 examples with one expectation in each all fail at the same time, you have 4 data points which provide insight into the problem. If all 4 expectations are in one example, you only get 1 data point. The biggest offences of this, however, are scenarios in which the subject's state is changed multiple times with expectations at each state. -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
