Test Cases vs. Examples

Before BDD and tools like RSpec took off, tests were often written in a "test case" style: they were phrased in the computer's terms. Well-written RSpec usually approaches testing from the human direction: instead of focusing on the software's terminology, the human-visible behavior is specified in English, and the examples map those English descriptions onto software terminology. In this screencast we'll refactor part of Hamster's test suite, translating it from a test case style to an example style. This will require many trade-offs, most notably trading completeness of test coverage in some corner cases for readability of test names.

Note: There's a bug in the mutation test that I missed during recording. Because RSpec's "let" variables are memoized, the "empty" value is only computed once. If it were mutated, both references to "empty" would point to the mutated value, defeating the test. As pointed out by Myron Marston, the test would even pass for Ruby's Array class, which clearly mutates. Unfortunately, mistakes like this are possible when validating a test by breaking the test itself, rather than by breaking the production code.