Professional Ruby on Rails™

7.4. Behavior-Driven Design

One thing you may have noticed about shifting to mock object validation is that it alters the very nature of the kinds of testing that you perform in your unit tests. Traditional unit tests, which perform most of their validation via assertions, are testing the state of the application. A mock object test, which is validating the calls made during the test against a predefined expectation, is testing the behavior of the application. The behavioral test is, at least potentially, more readily capable of separating the intended behavior of the program from the specific implementation being used.

Advocates of the flavor of automated test development called Behavior-Driven Design (BDD) attempt to move the test design closer to the problem space than to the implementation space, in part by designing the BDD tool sets so that tests can be specified in an idiom that is closer to natural language. BDD toolkits make extensive use of mock objects both as a way to specify the problem domain and as a way to separate individual unit tests from each other. Using traditional TDD tests, a change in a low-level method can cause multiple tests to break. A BDD advocate would argue that the fact that a single code change can trigger multiple test failures means that the tests are not truly unit tests, but in fact are integration tests, although at a very small scale. Where a TDD style of testing might use mock objects only in cases where the real object is unavailable or ...