views:

157

answers:

2

If a customer has a requirement - product names should not be more than 50 characters long, does this suggest a story/spec should be written for this if the framework being used already has a well tested validation framework (Rails for instance).

To be more general, should one test the specifics for each area of validation for the particular project (i.e. in the above example validates_length_of would be the area, length of 50 characters would define the specifics)?

This leads to the question of what areas of an application should be tested, and how does one differentiate these areas? Are there best practices in this area?

+1  A: 

What should be tested? Good question. In my opinion, every specification (in the Product Requirement Document) should be tested.

Each requirement should be tested in a positive (happy day) scenario as well as a negative test (when things go wrong) AT A MINIMUM. Then, you should design test cases to include boundary conditions (0 characters, 49, 50, 51, 256, 1000 characters, etc.) and blatant error conditions (illegal characters included).

So, each requirement should have MANY test cases to cover the functionality and error checking.

BoltBait
And the corollary: If it can't be tested, it's not a requirement.
Wayne Conrad
+3  A: 

Have a read of the pragmatic unit testing summary card.

Si