No knock on Kent Beck's book but IMO the best book that will help you understand and get better at TDD is a one that's not explicitly about TDD:
Corey Haines "Understanding the 4 Rules of Simple Design"
If you're a beginner, I doubt you'll find anything specifically about testing interfaces in either book though. I think that's a nuance that you'll only recognize when you understand how TDD is supposed to be done. Here's my take on testing interfaces:
1. Tests that are written against an interface will be "abstract" by nature because interfaces are not executable, unless your interface has default methods as introduced in
Java 8. Generally, however, the tests you define for an interface should pass when run against
any and all current and future implementations.
2. Following from #1, you'd probably want to set up a unit test for an interface's API as an abstract class that will be extended by tests that provide a specific implementation.
I don't see the code that you provided as being specifically tied to a test around an interface. I would probably write tests like this:
As I said, TDD is a way to think about design and drive that thinking with tests. These tests would probably make me think about the need to implement equals() and hashcode() since it would be surprising to have a compareTo() that is based on # of likes but still have equals() be inherited from Object, which only checks for reference equality -- there's a lack of symmetry there that should be address to make the BioPic class more complete and avoid surprises later on.