Destroy All Software Screencasts

[...] , 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, [...]

[...] 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 [...]

[...] could be replaced with `post :foo, :id => 12, :format => :js` in the test, leaving the production code unchanged.) [...]

[...] API access out into a wrapper, simplifying the original class and adding clarity to both the production code and the tests. [...]

[...] , 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 [...]

[...] thinking about this week's screencast, I happened to do a pretty big refactoring on one of Destroy All Software's controllers. I translated a confusing mess of exception rescuing into a more sensible [...]

[...] a sequel to the original Extracting Domain Objects screencast. Once again, we'll look at Destroy All Software's catalog logic, pulling it out of the Django View (equivalent to a Rails controller), and [...]

[...] implicit, and adding explicit abstraction layers. We'll look at an example from Destroy All Software itself, a Rails app, and pull a piece of model logic embedded in a controller out [...]

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 [...]

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 l [...]

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 [...]

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 actua [...]

[...] "fragility" and "brittleness" get thrown around: proponents of integration tests claim that mocking is fragile; proponents of mocking claim the opposite. It turns out [...]

[...] presented together. First, recommendations about general test design: 1) separate unit and integration tests, and 2) use alternate constructors to simplify test object creation. Then, recommendations [...]

[...] 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, [...]

[...] (acceptance and unit), and using many of the design principles discussed in earlier Destroy All Software screencasts. [...]

[...] Most Destroy All Software screencasts have used Vim, so let's take a moment to appreciate Emacs, the other "One True [...]

[...] In most Destroy All Software screencasts, the tests are run synchronously: the test process is forked from the editor and [...]

[...] 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 [...]

Several Destroy All Software screencasts have touched on isolated testing, but never addressed it directly for its own sake. That's the topic of this [...]

[...] app, and pull a piece of model logic embedded in a controller out into its own class with isolated tests. [...]

[...] 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 [...]

[...] 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 [...]

[...] constructors to simplify test object creation. Then, recommendations about using test doubles like stubs and mocks: 3) name your stubs for debugging and clarity; 4) don't stub [...]

[...] 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 [...]

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 [...]

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 fee [...]