I really like the idea of testing the interface of the base Bicycle class, but I'm having that "someone on the Internet is WRONG!" feeling when I get to the section "Testing Concrete Subclass Behavior".
Specifically, you write "The RoadBikeTest should ensure that local_spares works while maintaining deliberate ignorance about the existence of the spares method. The shared BicycleInterfaceTest already proves that RoadBike responds correctly to spares, it is redundant and ultimately limiting to reference that method directly in this test."
The thing is, though, that--at least as written in the Rough Cut version of the book I'm looking at--the BicycleInterfaceTest doesn't prove that RoadBike responds correctly to spares. It only proves that it responds to spares.
So I went off to recreate the code locally to make sure that what I was seeing was correct, and sure enough, I can comment out the entire method body of Bicycle#spares, and all the interface tests pass because they're just checking #respond_to?.
(Oh, and in the process, I also noticed that there's a method name collision between BicycleInterfaceTest and BicycleSubclassTest, which both define #test_responds_to_default_tire_size. Which I guess is acceptable, but feels icky at first glance.)
I'd be satisfied with this if we had a test that defined the return value of... um... oh, hey, I wonder if you cover this in the very next section?
/me skips ahead, sees "Testing Abstract Superclass Behavior"
...why, yes. Yes, you do. Carry on. (=
Seriously, though: if it's not already too late in the production process, it might be worth at least commenting that this is coming up, and/or removing the word "correctly" from the phrase "responds correctly to".