The test in the section titled Programming by Intention was the first test written in the project it came from. It was written as shown and no other code had been written yet. Why is this significant? Well, if we look at the test code we will see that it makes some assumptions:
there is a class called MovieList,
MovieList has a zero-argument constructor, and
MovieList has a method named size which takes no parameters and returns an int.
Making these assumptions as we write tests (and later when we write the real code) gives us the ability to design interfaces from the point of view of code that will use them. This allows us to choose names that make sense and that read well, that is, are understandable and clear. It also allows us to decide what behavior is required from a much better point of view: again, that of the client. This limits the behavior to exactly what is required, which lets us write less code, which lets us work faster, which lets us deliver sooner and more often.
How does this let us write less code? Primarily by deferring the addition of any code until it is proven to be required. This not only includes implementation detail, but also the existence of classes and methods. You do not create a class until you have a test that creates an instance of it. Likewise, you do not add a method until you have a test that calls it.
When you are writing code (especially tests), write what you want, without worrying about how to do it. Make up the support classes, methods, and variables you want and worry about their implementation later. This keeps you focused on what you have in mind at the time. The compiler will remind you about the assumptions you made.