I can (and will if this doesn't convince you) rewrite the tests to be on `RecordSet` but it seems inefficient. Moving the tests will make it harder to debug future failures because the test will necessarily execute more code. Having part of this classes public interface tested only implicitly in some other classes tests will make it harder to understand the actual required behavior. Testing this in `RecordSet` will also slow down the tests because it will require actually persisting the records in the database.

`hydrate` is a required public method of all record classes but is a member of a protocol/interface only necessary for code that retrieves records from the database. Ime, designing and specing each class in isolation from the code that uses it (but keeping it's required behavior firmly in mind) tends to produce much simpler, more well encapsulated and cohesive classes, which in turn results in easier to understand systems. I don't think who will be using a particular method should influence whether is it gets tested. Though, organizing the spec into protocol/interface sections can work really well.

I will definitely add back the `@private` annotation since you asked.  Personally i find the use of `@private` and `:nodoc:` really annoying as a user of libraries. Whenever i am looking at documentation there are always many methods that are not relevant to what i am trying to accomplish. If they have good names and documentation i can easily tell what is relevant to me at the moment. However, i often find that the methods for which libraries have withheld documentation are, in fact, relevant. At the very least, without seeing the actual public interface for a class it is often very difficult to build a good mental model of how the library will behave.