The purpose of this kata is to practice dealing with expensive and hard-to-test infrastructure at the outgoing side of an application (in this example, a database).
- How could we develop this using mostly fast unit tests?
- Do we have to use mocks in this case? What are the alternatives?
- Can we make sure that we can easily and safely replace the database in the future?
- How do we properly abstract and separate the code that is hard to test from the code that is easy to test?
- And how do we design our tests, so that they assist future refactorings?
Follow the steps one by one and do not read ahead.
There is a database library in the db package called Db and you don't own it, so you are not allowed to change it either.
It is annoyingly slow!
Program a Bookshelf that can create and store books and use the given database for it.
For now, books should only have a title.
It is not necessary to create a UI, CLI, or any other complicated User Facing Interface for this.
A simple service class/module/function will do.
We would like to be able to skim the books we have added so far. Add a feature that allows us to retrieve all books that were stored on the Bookshelf.
Let's add more spice to the Bookshelf. Mark every 10th book you add as an anniversary book.
We really love our Bookshelf so far. We added so many books, we would like to celebrate that. Therefore, every 25th book we add should be marked as a golden anniversary book. Note that a book can be either an anniversary or a golden anniversary book, but not both.
A new version of Db came out. It's much faster, but they renamed the persist function.
And it has a new feature where you can get the count of stored objects.
This should help with the anniversary features.
Migrate to the new version, it's located in the db2 package.