I need a document database. Why? There are areas in my problem generating (How to calculate 17 billion similarities) pet project cookit that are just asking for a document modelling approach.

Most people will say that this is a straightforward problem to solve:

It is NOT a good idea.

This post is a continuation of a previous tips, tricks, and good practices for Data-Driven Testing entry. This one with more code.

As promised here and here, this will be tips, tricks, and good practices for data-driven tests.

If You want to know more about data-driven testing see my previous posts on this topic.

Here we go.

The previous post was meant to be an encouragement and a warmup to data-driven testing. This post describes why I love this way of testing. Understanding a simple fact about testing moved me from “Oh, I should write tests” to “I want it all! And I want it now!” and Data-Driven Testing. And the simple truth is:

I am not a big fan of writing tests. I like having them, but I find writing them to be boring. That said, retesting manually is even more annoying, so I write tests. The thought that there has to be a better way, never passed. I tried a few approaches. After some experimentation, I think I have the answer - DDT (Data Driven Testing)