I'm new to Unit Testing, and I'm only getting into the routine of building test suites. I have what is going to be a rather large project that I want to build tests for from the start.

I'm trying to figure out general strategies and patterns for building test suites. When you look at a class, many tests come to you obviously due to the nature of the class. Say for a "user account" class with basic CRUD operations, being related to a database table, we will want to test - well, the CRUD.

• creating an object and seeing whether it exists
• query its properties
• change some properties
• change some properties to incorrect values
• and delete it again.

As for how to break things, there are "fail" tests common to most CRUD classes like:

• Invalid input data types
• A number as the ID key that exceeds the range of the chosen data type
• Input in an incorrect character encoding
• Input that is too long

And so on and so on.

For a unit test concerned with file operations, the list of "breaking things" could be

• Invalid characters in file name
• File name too long
• File name uses incorrect protocol or path

I'm pretty sure similar patterns - applicable beyond the unit test one is currently working on - can be found for most units that are being tested.

Now my question is:

• Am I correct in seeing such "breaking patterns"? Or am I getting something completely wrong about Unit testing, and if I did it right, this wouldn't be an issue at all? Is Unit Testing as a process of finding as many ways to break the unit as possible the right way to go?

• If I am correct: Are there existing definitions, lists, cheat sheets for such patterns?

• Are there any provisions (mainly in PHPUnit, as that's the framework I'm working in) to automate such patterns?

• Is there any assistance - in the form of check lists, or software - to aid in writing complete tests?