I think immediately "breaking" rule 1 is sometimes necessary. For example, if I am writing unit tests in Java, most of the time I'll need to create some POJO / model classes to be able to write and compile the unit tests in the first place.
Also, I think you should be careful with this approach to TDD. While what you did made sense, because there is a connection to a database, this becomes more integration testing as opposed to unit testing. Mocks come into play here so that integrations can be mocked and therefore unit tests stay de-coupled.
There are some interesting thoughts here.
I think immediately "breaking" rule 1 is sometimes necessary. For example, if I am writing unit tests in Java, most of the time I'll need to create some POJO / model classes to be able to write and compile the unit tests in the first place.
Also, I think you should be careful with this approach to TDD. While what you did made sense, because there is a connection to a database, this becomes more integration testing as opposed to unit testing. Mocks come into play here so that integrations can be mocked and therefore unit tests stay de-coupled.
Greatly appreciate the tip regarding mocking my connection to the database, I'll have to look more into it.