Following the discussion in #36, the dedicated rule-checking methods should each verify only the single validation rule they are responsible for, rather than comparing against the complete error array for a field.
PR #37 introduced testDataValidationContains(), which asserts a specific validation error key independently of other validation errors on the same field. This avoids problems like testDataValidationScalar() also asserting an unrelated maxLength error that CakePHP may apply.
All remaining type-specific/rule-dedicated methods should be refactored to only assert their own rule, consistent with the testDataValidationContains() approach.
Note that this is a breaking change: existing tests relying on the full-error-array comparison will need updating.
The ability to pass custom $expected values should remain available.
Following the discussion in #36, the dedicated rule-checking methods should each verify only the single validation rule they are responsible for, rather than comparing against the complete error array for a field.
PR #37 introduced
testDataValidationContains(), which asserts a specific validation error key independently of other validation errors on the same field. This avoids problems liketestDataValidationScalar()also asserting an unrelatedmaxLengtherror that CakePHP may apply.All remaining type-specific/rule-dedicated methods should be refactored to only assert their own rule, consistent with the
testDataValidationContains()approach.Note that this is a breaking change: existing tests relying on the full-error-array comparison will need updating.
The ability to pass custom
$expectedvalues should remain available.