You've jumped the gun already with TDD because you've written some implementation without writing a testfirst. TDD stands for Test Driven Development which discusses a method of programming where your tests drive your implementation which implies you write your tests first.
You'll have probably found already a whole bunch of information about TDD on the internet, some proposing it, some condemning it, and lots of conflicting information in-between. My recommendation to grasp the original essence of TDD without getting clouded by all the chaff that followed is to pick yourself up a copy of Kent Beck's "Test-Driven Development by Example". The book is from way back in 2003 but don't be put off, it's a great read.
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.