BUY CLASSIC SEASON 4

CLASSIC SEASON 4



Lesson 1

In this series, we'll rebuild Sucks/Rocks from scratch. It's currently broken because the services it relies on have been discontinued. We'll rebuild it as a Rails app using both TDD loops (acceptance and unit), and using many of the design principles discussed in earlier Destroy All Software screencasts.


Lesson 2

In part two, we begin the unit-level TDD for Sucks/Rocks. I try to explain every little decision I make as I'm TDDing: how the examples are chosen, when to generalize, and how to force the code to return a specific data type.

Lesson 3

In part three, we integrate Bing as our search engine source, using VCR for record/playback of interactions when testing it. We also get our first passing Cucumber scenario, but find a bug in the process.

Lesson 4

We now add a caching layer to Sucks/Rocks. It's another plain old Ruby object that uses the RockScore service. This is part four of the series, and in it we add our third class, but we still don't need any Rails at all!

Lesson 5

In part five, we go back and fix the bug that we found in part three. Then, we complete the caching layer by pushing down to the ActiveRecord model. Finally, five screencasts in, we introduce a database schema and use Rails.

Lesson 6

Finally, we actually serve the new Sucks/Rocks app as a web site. Using the old static assets, we introduce a tiny controller method to wire our services up to to Rails. This ends up revealing a bug, which we write a test for and fix.

Lesson 7

In the previous part of this series, we did some exploratory testing to ensure that the controller was working. To avoid repeating that work in the future, we'll automate it by writing more Cucumber tests. In the process, we'll find and fix yet another bug.

Lesson 8

In the last part of the series, we start by elevating the Cucumber features to run against the full stack, not just the service layer. Then, we step back and look at the whole design: how could we have handled NoScore without a sentinel? What was the result of the obsession with avoiding nil? And how would the design allow us to easily switch to a new search engine? The full source of Sucks/Rocks is available on GitHub.

Lesson 9

In this screencast we'll derive my git log format from scratch. It has one line per commit without sacrificing detail, with each field colorized and aligned in its own column. Along the way, we'll see a couple of command line tricks—column and various arguments to less—that haven't appeared in a screencast before. My gitconfig and githelpers files are both available on GitHub.

Lesson 10

The Tell Don't Ask principle tells us not to manipulate objects conditionally based on their state; instead, the knowledge of when to manipulate belongs in the object. That sounds like a rule about mutability, but it's not: it applies just as well when objects are immutable. This screencast will look at an example of "asking", convert it to a "tell", and examine the role (or lack thereof) of mutation.

Lesson 11

Python's namespacing and module system make it possible for a testing tool to enforce test isolation automatically. We'll test drive such a tool from scratch, though it will be a rough implementation (it won't undo its changes after tests complete, for example). This will give us the chance to see several features of Python that are missing in Ruby.

Lesson 12

Paying close attention to your tests can highlight design problems in production code that you might not notice otherwise. Here, we'll look at an example that occurred during the development of Raptor: the tests contain deep stubs, irrelevant names, and a rectangular shape, all of which point to a design problem.

Lesson 13

When first learning about mocks and isolation, it's tempting to overdo it, and I did. We'll look at a test that I wrote several years ago and examine its obsession with mocking. As we do that, we'll refactor it to be simpler, more direct, and with less indirection via mocks.

Lesson 14

To show that Bash really is a full programming language, let's test-drive a shell script. We'll have all of the familiar tools from xUnit style testing tools, like setUp methods and assertions.

Lesson 15

Removing conditionals can sometimes reduce complexity. However, the benefits aren't so obvious in this example. We'll replace a conditional five times, each using a different language feature, and see how it impacts the understandability of the code.

Lesson 16

This time we build a script that can run a process, wait for it to start listening on a socket, and then kill it. This is useful for benchmarking a web framework's (or even a web app's) startup times. We also compensate for error in the measurements due to cold cache effects and due to constant costs introduced by our script itself. The script is available for download if you'd like to use it.

Lesson 17

In this screencast we TDD the same code twice: once in the traditional, imperative OO way with mutation; then again in a functional way by returning a value.

We look at several differences between the two implementations, but the most interesting is in the way that they're isolated. Though both are isolated against external behavior, only the OO version requires mocks. The functional version achieves isolation by taking a value in (a Tweet value object) and return a value out (an array of strings to be rendered). This saves us from the danger of mocked methods going out of sync.

Note 1: For realism, the tests are written in exactly the way that I naturally wrote them on my first practice run. This does make the OO version slightly more complicated; the mocking could be simplified but, of course, it can't be removed. Additionally, since this is how I wrote it originally, it shows how easy it is to introduce accidental complexity when mocking in tests.

Note 2: The magic numbers that I claim have "disappeared" in the functional version are still present in the padding numbers (" " * 16, etc.) This was simply sloppy language on my part; I should've said that the tests and production code together remove the magic from the numbers. The production code contains the details, whereas the tests give a clear high-level view of what's happening.

Lesson 18

Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to the screen?

In this screencast we look at one method for crossing this divide. We review a Twitter client whose core is functional: managing tweets, syncing timelines to incoming Twitter API data, remembering cursor positions within the tweet list, and rendering tweets to text for display. This functional core is surrounded by a shell of imperative code: it manipulates stdin, stdout, the database, and the network, all based on values produced by the functional core.

This design has many nice side effects. For example, testing the functional pieces is very easy, and it often naturally allows isolated testing with no test doubles. It also leads to an imperative shell with few conditionals, making reasoning about the program's state over time much easier.