Summary: Long before writing code, there are many decisions to make. Each decision can have a profound and lasting effect (you might even say a legacy!), whether thoughtfully considered or not. When teams share a common vocabulary for decisions and the context in which decisions are made, decisions can be made more effectively.

• In part 5 of this discussion of "generative testing", we began to see areas where randomly generated data didn't quite fit into the unit testing way of doing things.
  • Tests need to be extensible, so it often isn't sufficient to merely provide one set of generators for use in all tests. We will look at ways of selecting arbitrary generators to use for particular tests.
  • It is easy to generate a bunch of random tests, but when you try to run a specific test again, that example may not have been generated again, then the testing framework can't find the test because different tests were generated each time (both a help and a hindrance). How do generative testing frameworks help?
    

In part 4 of this discussion of "generative testing", we began transforming and assembling these generators to do much more powerful tasks. This time we will compose better sheepish-like strings in an attempt to trick the sheep-bleat? function with our unit tests.

In part 3 of this discussion of "generative testing", we started generating a simple types of data, integers and constants, but in order generate data useful for complicated applications, we'll need to assemble these generators to do much more powerful tasks.

In part 2 of this discussion of "generative testing", we skipped the first word, "generative", and went straight to "testing." This time, we'll move back to automatic test-case generation.