vendor/plugins/rspec/doc/src/documentation/rails/writing/notes.txt

   1
   2 There
   3 are two opposing forces that guide decisions about how to structure specs in relation
   4 to the code being specified:
   5
   6 * Rapid Fault Isolation. When we introduce a bug in the system, we want (ideally) only ONE
   7 spec to fail. We certainly learn something when several fail, but it is often a sign
   8 of coupling not only in the specs, but in the design as well.
   9
  10 * Freedom to Refactor. When we want to change implementation without changing
  11 behavior, we want to do so without changing specs. This is a core tenet of TDD
  12 and an even more obvious part of our approach to BDD. Behaviour is its first name.
  13
  14 The tension created between these two forces is that Rapid Fault Isolation
  15 guides us to write specs that are as close to the implementation as possible, while
  16 Freedom to Refactor guides us to write them as far from the implementation as
  17 possible.
  18
  19 BDD is all about balancing these two forces. There is no right answer as to how
  20 to do this. The best advice we can give is to be aware of these two forces and
  21 be aware of the effects of one pulling harder than the other.