[C]ORRECT: [C]onformance

[C]onformance: Conform to a specific format

Many data elements must conform to a specific format. For example, an email address generally follows the form: name@somedomain

The name and domain portions of the address each follow a different set of fairly detailed rules. Imagine that we want to validate the conformance of an email address to these many regulations.

Perhaps our code parses an email address in an attempt to extract its name portion (the part leading up to the @ sign). What we really want to know is what to do if there is no @ or the name portion is empty.

Note: How to design the code is pretty flexible. You might choose to return a null value or an empty string or even throw an exception. Regardless, we need to write tests that demonstrate what happens when each of these boundary conditions occurs.

Validating formatted string data such as email addresses, phone numbers, account numbers, and file names might also involve many rules, but they are usually straightforward. More complex structured data can create a combinatorial explosion of cases to test, however.

Testing boundary conditions

Suppose we’re reading report data composed of a header record, some number of data records, and a trailer record. Here are some of the boundary conditions we will need to test:

• No header, just data, and a trailer
• No data, just a header, and trailer
• No trailer, just a header, and data
• Just a trailer
• Just a header
• Just data

It gets easier to brainstorm how data doesn’t conform to the expected structure the more one does it. We’ll find more defects in the process because they often live around the interesting boundaries of our system.