Add
Private Notes
OK, so I completely blew it. For a year now I've been promising you this episode on advanced TDD. Tease, tease, tease -- advanced TDD. Blah, blah blah. So then, when I finally started writing the script for the episode, I realized that the script was far too long for one episode, and I wasn't even halfway done with the topics I wanted to cover!
So, I backed off and did a topic analysis on what I wanted to talk about, and found I had three or four episodes worth of material. I gathered the first topics together, and set the others aside for later. And then I finished off the script for the first episode.
Then, after shooting and editing, we realize that the episode is two hours long! Woah! We need to split it again!
So, here it is. Episode 19, part 1. Advanced TDD.
In this episode we're going to do a deep dive into the three laws of TDD; with lots of code examples. We'll study the process of TDD in minute detail as we gradually build a simple program to invert names.
As we explore the three rules, we'll also start the discussion about The Single Assert Rule; and then we'll set that aside for more exploration in a future episode.
So, wash your eyes out and clean your glasses, because this one's all about the code. And get ready for the first half of Episode 19. Part 1. Advanced Test Driven Development.
So you've watched Part 1, right? I mean, you don't want to start with Part 2 because you'll miss all the preliminary discussion on the three laws. So, just checking.
Part 2 is where things really start to get interesting. First we look at the topic of incremental algorithmics; the notion that you can derive an algorithm, one step at a time, by posing a failing test, and then making that test pass.
As part of this process we'll learn one of the most foundational principles of Test Driven Development. The principle where the magic really comes from. As the tests get more specific, the code gets more generic.
And then... and then... Well, then we go and get ourselves stuck; Stuck is a technical term that means: Stuck. In TDD when you are stuck, it means that in order to make the currently failing test pass, you've got to implement the whole program. It means there's no incremental step to take, no simple solution, no easy path.
So first we show you how to get stuck -- because there's nothing quite so informative (and fun) as watching Uncle Bob fail. Then, we back up and show you how to get unstuck, and how to avoid getting stuck in the first place.
And then we're done. Uh. Well. With Episode 19. But that's just the first of many episodes we're going to do on Advanced TDD. So, keep watch for more.
Woah! Twenty episodes! Wow! That's almost a full 24 hours of video. Who'd have thought that I had 24 hours of stuff to talk about? Who'd have thought that after nearly a full day of talking I'd have so much more to say!
Anyway, in celebration of the twentieth episode, we've included a couple of extra features for your enjoyment. We hope you'll like them. We sure had fun making them!
This episode is all about Clean Tests. We begin by examining the anatomy of a test: The four A's: Arrange, Act, Assert, and Annihilate. We spend a lot of time talking about the various forms of the Arrange.
Next we talk about the problem that setup functions can grow to become unmanageable; and we address that problem by introducing the fascinating topic of hierarchical tests. We show how hierarchical tests are natural in Ruby using Rspec, and how to implement hierarchical tests in C# and Java.
Finally, we put the icing on the cake by showing you how to create truly clean and readable tests by using the technique of test composition.
So get ready for a dimensionally transcendental experience, as we materialize inside the world of Clean Tests!
Those are some of the things you are going to learn in this episode of Clean Code. Episode 21: Test Design.
And the bottom line is this: Tests are part of the code of your system. They are not a different class of code. They are not a different species of code. They are not somehow inferior or less important. The code in your tests is part of the code of your system! And therefore the code in your tests has to be planned, and designed, and cared for with the same zeal, and effort, and conscience as the production code!
The penalty for failing to hold your test code to the same high standard of your production code, is that your tests will rot, and your production code will follow.
So, no pressure or anything, but in this episode you're going to learn some of the rules, techniques, and principles of: Test Design.
Have you ever heard of: Fake It Till You Make It? How about: Assert First or Test Triangulation? These are just some of the test writing techniques that we'll cover in this episode -- and cover with lots and lots of code.
Then we'll face the ultimate existential question of tests: What's more important, the tests or the production code? Indeed, we'll pose it a problem of two disk drives; one containing the tests and the other containing the production code. One of them has crashed. Which do you hope it is?
How much of your refactoring effort should be spent refactoring the tests? Any? And if you do refactor the tests, what is the goal of that refactoring? What does a good clean test look like?
Kent Beck often says: "First make it work. Then make it right. Then make is fast and small."
Ron Jefferies' rules of Simple Design tell us that the code should:
Pass all the tests.
Have no duplication
Express everything the author wants expressed.
Have a minimum of classes and methods
What do these rules have to do with tests? Should they be followed when writing tests? Or is there a different set of rules for tests? The answer may surprise you.
Finally, we'll talk about the term: Test First, and find out what it really means.
So get ready to read lots of code, to think lots of thoughts, and to face the ultimate truth of test driven development.
EGAD! Another two-part episode! I just can't seem to get this advanced TDD topic under control! So, this is part 1. Remember to get part 2!
OBAFGKMLT
Welcome to Clean Code Episode 23 - Mocking; part of our sub-series on advanced Test Driven Development. In this episode we're going to learn about Test Doubles and Mocking.
We begin with a little puppet show. You'll recognize the characters. You'll also recognize the situation; because, in all likelihood, you've been there - done that. That situation will lead us to a software architecture replete with dependency-inverted boundaries. As the players in our drama discuss how to test the features in that architecture, we'll gradually make the case for using mocks.
Then we'll show you those mocks in a sequence of screencasts that begin with basic stubs and moving on to more involved spies. There's a lot of code to look at; and of course you can download it all from the extras link.
Then we get all academic and study the classification of Test Doubles. We talk, in depth, about dummies, stubs, spies, mocks, and fakes. And there is plenty of code describing each.
All that takes an hour. And at the end of that hour, part 1 comes to an end. But don't forget to watch part 2, because things get pretty interesting over there.
In part 2 we're going to learn about the never ending struggle between Behavior and State; and the remarkable stress this dichotomy puts on our mocking strategies. This will lead us to: The Uncertainty Principle of TDD and the never ending battle between the Mockists and the Statists.
Then we'll get all pragmatic and start examining some of the most useful mocking patterns such as: Self-Shunt, and Test-Specific Subclass, and my favorite: Humble Object. We'll show you, with lots of code, how and when these patterns should be applied.
Indeed, we'll use the Humble Object pattern to show you how to test GUIs. We get a little Swing UI up and running and then show you how to separate the
Yikes! Another two-parter. These topics just keep getting bigger and bigger.
OK, so what the devil is the Transformation Priority Premise? Well, it's an idea that's kind of at the front lines of Test Driven Development. The Bleeding Edge, so to speak.
The notion is pretty simple. You know what refactorings are, right? I mean they're small modifications to source code that change the structure of that code without changing the behavior. Well, a transformation is just the opposite. It's a small change to software that changes the behavior, without changing the structure.
Would it surprise you to learn that the number of transformations is relatively small -- perhaps only a dozen? Would it also surprise you to learn that these transformations fit neatly into the red-green-refactor loop of TDD? Finally, would you be surprised if I told you that some transformations are "better" than others?
In this episode we'll identify an even dozen of those transformations. First we'll walk through a familiar Kata (the Prime Factors) and show how a few transformations are used. Then we'll walk through each transformation in turn, and describe them in detail.
And that'll take the hour; and will bring part 1 to a close.
In Part 2 things get really exciting. Because in Part 2 we explore the notion that these transformations have an ordering, a priority, that helps developers create better algorithms better code, and better design. But that's part 2. No fair peeking.
OK, so this is Part 2; and this is where things get really exciting.
I'm sure you've seen me do the Bowling Game, the Prime Factors, and the Word Wrap katas. You know how those algorithms just seem to kind of appear, as though the code was writing itself?
We'll we're going to see that again. But this time we're going to see it in the context of applying transformations using a certain priority. In fact, we'll do it twice, with two different priorities. And then we'll examine the different.
The difference will be (how do I say this without giving too much away?) -- interesting. Very interesting.
Finally, we'll state the premise. We'll also make the point that it is no more than that. It's not a law, not a principle, not a theory, not even a conclusion. It's just a premise. But if it's even partially correct, it's a premise that could have a significant impact on our profession.
Or not.
Anyway, enjoy the episodes.
