BUY CLASSIC SEASON 3

CLASSIC SEASON 3



Lesson 1

Several screencasts have talked about moving logic out of models and into naked Ruby classes, but what are the things we should leave behind in the ActiveRecord models? That's what we'll address here: a walk through the types of methods that belong on AR models, and why they belong there.


Lesson 2

In the second part of this series, we'll actually remove the various parts of the model that don't belong, as shown in the part 1. Most of the time will be spent removing the two ActiveRecord callbacks, replacing them with a class that sits between the controller and model, mediating the lifecycle of the User and Braintree API objects. We'll also briefly replace the other two methods with implementations outside the ActiveRecord class.

Lesson 3

When doing TDD from the outside in, stubs are the norm. We build the outermost class first, stubbing its dependencies, which may not even exist yet. Those stubs tell us what the interface of the next layer down should be; this is how TDD drives the design. When we're not isolating our tests, though, we can't do this. We can still start at the top, but we can't make the test pass without an actual implementation. This can lead to large, unwieldy commits. We'll look at how to avoid those large commits using the git stash, and then compare the results of outside-in TDD with stubs vs. outside-in TDD with the stash.

Lesson 4

With 40 screencasts in the catalog, many of which discuss testing, we now have enough context to talk about when to test in isolation and when to integrate. It comes down to one main question: who owns the interfaces you depend on? We'll go through the major components in a modern web app, looking at why each can be tested in isolation or not, or why they're somewhere between those extremes, and see exactly why each one falls where it does.

Lesson 5

This is part one of a three part series on dealing with legacy code. We'll start with a completely untested Rails controller, put tests around it that cover all of the cases, and then extract pieces of the code safely using the tests, while simultaneously pushing the tests down to lower levels of isolation. In this screencast, we introduce the code and try to create an exhaustive list of pending RSpec contexts and examples.

Lesson 6

In part 2 of this series, we write actual tests for the context structure we discovered in part 1. Along the way, we'll verify that each test is actually testing something by breaking the code in a very small way to see it fail. (Ideally, this would cause an assertion failure each time; some erroring tests are allowed to slip by for speed's sake.) (The respond_to block used in this screencast could be replaced with `post :foo, :id => 12, :format => :js` in the test, leaving the production code unchanged.)

Lesson 7

Now that we have tests, we can finally refactor! We'll do some minor cleaning on the structure of the controller action, and then extract some model logic into a new model method. During the process, we'll disentangle the book-finding logic from the book-adding logic. This will allow us to extract the book finding logic in part 4, reducing the controller to very little code.

Lesson 8

In the final part of this series, we pull a large piece of code out of the controller, moving it into its own class. That class is tested in isolation by using the controller's integration tests as a guide. While doing this, one of the tests stands out with very complex stubbing, so we make a small design change to simplify it. Finally, we step back and look at the final suite of tests we've created.

Lesson 9

Most Destroy All Software screencasts have used Vim, so let's take a moment to appreciate Emacs, the other "One True Editor". We'll look at some of my customizations from my past as an Emacs user, as well as some of the features I miss when I'm in Vim. (After publication, Avdi Grimm reminded me of Evil, which you may want to try for better Vim emulation in Emacs.)

Lesson 10

Writing fast tests often means testing without loading the rest of the application. When you want to stub a method on a class that isn't loaded, how do you do it? There are many ways, and here we'll quickly look at five of them, four of which have no test performance impact at all.

Note: After the publiciation of this screencast, RSpec gained a "stub_const" function. Using this is generally easier than creating an empty class, but provides similar results. The trade-offs are slightly different from the empty class approach, but almost all of the disussion in this screencast holds.

Lesson 11

The terms "fragility" and "brittleness" get thrown around: proponents of integration tests claim that mocking is fragile; proponents of mocking claim the opposite. It turns out that they're both right, and we'll look at why, then end with a look at an arguably incorrect use of the terms as applied to truly isolated tests.

Lesson 12

We revisit an old topic: computing statistics over a repository. This time, we have a concrete example taken from the Raptor web framework, which has its own statistics script that results in very detailed plots. Along the way, we'll see some shell details, including some confusing behavior from the `time` builtin. Raptor's statistics script and the run-command-on-git-revisions script are both available if you'd like to try them out.

Lesson 13

Destroy All Software coupon codes are each composed of three random Unix words, like "ls ruby fi". We'll build the coupon generation script from scratch. It starts with the list of man pages on the host system and turns them into random three-word coupon codes. Although the script is fundamentally one long chain of pipes, we'll take care to keep the names and structure readable throughout.

Lesson 14

How terse can Ruby class definition get without changing the language or impacting readability? We'll give it a shot in this screencast, finding it surprisingly easy to turn six lines of declaration into two. The resulting helper code has been cleaned up, had its monkey patches removed, and is available as a gem.

Lesson 15

When a TDDed test fails, you can often make it pass by "sliming": making the method in question return a hard-coded value, instead of computing the answer in the "right" way. When you write that slimed code, when should you generalize to the full implementation, and when should you write another test to force the generalization? We'll look at some specific cases where I jump straight to the generalization.

Lesson 16

By popular demand, we'll talk a trip through my .vimrc file—not a line-by-line examination, but a look at the most interesting parts that you might want to steal. We'll see tab key overloading, customizations to ease the rougher edges of Ruby syntax, and my system for running only the tests that are needed. My vimrc is on GitHub, as is the test running plugin that was mentioned.

Lesson 17

Pushing complexity down to lower levels is a common refactoring. We'll TDD a small class to work on, then look at two ways to push a particular conditional down to a lower level. One of them will result in a much better design than the other. This shows that merely pushing down isn't enough; sometimes it's simply redrawing the lines in the same bad design.

Lesson 18

When keeping tests small, they tend to repeatedly form a few consistent shapes. This time, we'll look at the three main test shapes that are relevant to mutability: immutability, local mutation, and global mutation (or, equivalently: nondestructive, locally destructive, and globally destructive). Then, we'll look at three ways that these tests can go wrong by being implementation-obsessed.