Modeling for Testing

Names:

This exercise touches on many of the topics we will address this semester. Don't be concerned if part of this exercise seem "fuzzy" now; by the end of the course, you will understand why I put each of the questions into the exercise.

Reconsider the whimsical system from in-class exercise 0.
In this exercise, we are going to build some models to help us test
more systematically.

If the moon is full and the sky is clear, release the monster. If the sky is clear and the wind is calm, release the monster.

- Formalize the input domain as simply as possible.
How can you develop tests from this model?
If the input domain model is more complex, does this approach still work?

- Build a graph model model that captures the logic of these requirements.
Create a minimal set of tests that "cover" the graph.
How many tests do you get, and how satisfying do you find these tests?

- Build a logic model that captures these requirements.
How many different test cases are possible,
and what is the outcome in each case?
Again, make the simplest possible choices.
As discussed last time, testing each possible case is probably not
the best approach - at least not for large numbers of boolean clauses.

- Develop tests that target each boolean clause.
Would you expect to find more problems than those specifically targeted by your model?

- Model what could go wrong from a programming perspective. There are multiple possible answers. For your model, is it possible to target test cases specifically at what could go wrong? Would you expect to find more problems than those specifically targeted by your model?