Chapter 1. Ruby under the microscope
Figure 1.1. For our graph, we will build a simple domain model: products will have purchases, which belong to the stores where they happened.
Figure 1.2. Our finished graph: in about 40 lines of code, we pulled data from the database, processed it, and graphed it in a rather attractive fashion.
Figure 1.3. Some languages create a gulf between your ideas and working code.
Figure 1.4. Ideas can more closely match the resulting code if your expertise and perspective create an overlap between the framing of an idea and the real code that will execute it.
Figure 1.5. Ruby can be bent to your problem domain, making the overlap between your problem domain and real code significant.
Chapter 2. Testing Ruby
Figure 2.1. Test-driven development is a five-step process: add, fail, code, test, refactor.
Figure 2.2. Test suites are composed of a collection of unit tests that are run one by one by a test runner.
Figure 2.3. The behavior-driven development process starts with specification, adds tests, and builds an implementation that matches the specification and passes the tests.
Figure 2.4. An HTML report showing successful, failing, and pending specifications
Figure 2.5. A stubbed class will seem to act like the real object but won’t actually behave like it. In this case, the stub doesn’t grab data from a remote service, but to the code consuming the API, it appears to.