BUY CLASSIC SEASON 2

CLASSIC SEASON 2



Lesson 1

We've seen a lot of Unix commands, but never stopped to talk specifically about building a large command. That's what we'll do in this screencast: we'll solve a problem using a large one-off command, but the goal is to think about the command itself. Along the way, we'll see most of the utilities you need to do text processing in Unix. If you learn each of these, you'll be able to manipulate text streams quite well.

Lesson 2

The tar pipe is my favorite Unix command. It combines several important Unix concepts around files, subprocesses, and interprocess communication in just a few characters. We'll look at the tar pipe and what it does, then dive down into what the shell is doing to make it work, including forking and the creation of pipes. We'll also look at some raw tar data, which you rarely see in the wild.

Lesson 3

Coupling and abstraction are closely related: by introducing a method to reify an abstraction, you often naturally decrease the coupling between two classes. We'll explore this with a simple model/controller example, as well as a case where the situation isn't so straightforward: a method call that looks like a good, simple abstraction but is actually dangerous because it's third-party. Finally, we'll see the way that isolated, outside-in TDD naturally encourages you to build good abstractions early.

Lesson 4

Isolated unit tests have many benefits, but one drawback is a loss of confidence in the integrated system. At high levels of isolation, you lack a feedback mechanism for learning that the pieces don't actually work together: for example, they call the wrong methods, or call them with the wrong number of arguments. This can make refactoring with isolated tests scary. In this screencast, we'll look at the technique I use as a first line of defense. It's a hybrid between fully isolated unit testing and slow, expensive integration testing.

Lesson 5

To spike code, you stop doing TDD, throw some code together without tests to learn something, then delete the code and do it the right way. In this screencast, we'll look at spiking, and specifically the idea of "continuous spiking": instead of throwing the code away, transitioning it into TDDed production code iteratively. It's a dangerous practice, but doing it with care can help you through unclear parts of your application development.

Lesson 6

In this screencast we look just at stubbing: not other types of test doubles, and not when to use a test double or not. We'll hit three stub-specific topics: the difference between incidental and essential interactions; a method for testing mix-ins without depending on a class that mixes them in; and creating more focused test examples by pulling out common stubs and mutating them for each example.

Lesson 7

This is the first of two screencasts showing a live refactoring of a large controller method. In the first half, we break the method down into smaller methods so that we can understand it better. In the second half, we'll reason about those small pieces, find good names for them, and clarify. The end goals are small, understandable methods; better names; reduced early returns, conditionals, and other control structures; and better clarification of intent.

Lesson 8

This is the second of two screencasts showing a live refactoring of a large controller method. In this half, we try to improve the names of all of our new methods by at least a little bit. Along the way, we extract some more fine-grained methods. At the end, we look at how breaking this class down makes it easy to move code out of the controller and into other classes. The final version of the class is available if you'd like to look over it.

Lesson 9

This is a follow-up to the two-part controller refactoring series. Here, we step outside the controller itself, moving small pieces of model querying and logic into the model. This clarifies the controller's intent, provides points for reuse, and simplifies testing of both the controller and the newly-extracted model methods.

Lesson 10

In this screencast, we look at Cucumber for writing high-level acceptance tests with examples taken from Destroy All Software's Cucumber suite. We'll touch on step naming and the abstract/detailed split between features and steps, as well as some performance tips and notes about browser engines.

Lesson 11

Returning to ChiliProject, we now extract some application logic from a model into some naked classes in lib. This results in removing code from the model, centralizing knowledge, eliminating duplication, and providing points for reuse. A method marked "This method [...] is to be kept as is" even gets refactored. (I'm sure it'll be fine!)

Lesson 12

This is a screencast full of tips for learning Vim. They range from introductory (how do I learn to use Vim effectively?) to specific questions I'm asked (what plugins do I use?) to advanced (how should I guide my use of plugins to maximize speed?), so there should be something for everyone. We also touch on color schemes a couple times: both my grb256 color scheme based on ir_black (available on GitHub) and Solarized, which is a more subtle choice.

Lesson 13

In this screencast, we once again analyze the history of a git repository. This time, though, we go further: we first generate a chart showing test runtimes across revisions, using only the command line. We then focus on a sudden change in runtime that the chart reveals, repurposing git bisect to make git find the commit that caused the change automatically.

Lesson 14

This time, we analyze the execution time of testing a small piece of behavior at four different levels: from Cucumber, from the controller, from the view, and from an isolated Ruby class. This lets us quantify the performance benefit of fine-grained testing and make more objective decisions about what should be tested at a given level.

Lesson 15

Cowboying a shell script is fun, but how do we test it? We'll look at a basic method in this screencast, using nothing except standard shell tools. In the process, we'll also see a simple method for using a git repository as a fixture for testing a tool that operates on it. Everything shown is Bash-compatible, though the screencast is a mix of Bash and Zsh.

Lesson 16

The bigger a single test is, the worse the feedback. We'll look at a test that's already good but can be split further, comparing the failure patterns it generates before and after splitting. By turning one test into three, we'll be able to understand the failures simply by looking at the test names, instead of having to analyze the actual assertion failures.

Lesson 17

In this screencast, we'll revisit the example from "Performance of Different Test Sizes", where we wrote similar pairs of tests at four different levels. We'll go through each level, asking which of those tests we should keep, and why. Along the way, we'll compare the layers a test claims to test to the layers it actually interacts with, and see how that indicates the quality of the test.

Lesson 18

A spike is a small, disposable experiment in code. After learning about your problem or solution via the spike, you throw it away and rewrite the code using TDD. Here, we look at a process for doing that incrementally, using the spike as a guide and git's rebase functionality as the means. It's only appropriate when the spiked code is heavily constrained by external interfaces. But, in that case, it can guide you through tricky third party interactions. Because this is a subtle topic, the screencast is necessarily demonstrating a simplified form: the spiked and TDDed code are identical. When doing this in practice, the rebases will result in nontrivial conflicts since the implementations won't be identical. The more dissimilar they are, the closer you are to true test driven design, and the less useful this technique is.