A recent problem I had with the DataValidationTestTrait was the “testDataValidationIsUnique” method.

The problems with it were:

1. It was badly documented. I was not aware that the “fieldValue” was not supposed to be an already existing value, since that would make sense to test. It creates its own new entry and then does that again, which should lead to an error because of a Unique field.
2. The validation had to be turned off. To test uniqueness you have to test the buildRules which trigger after the validation.
3. If there are fields that are “not null” in the database, you have to set them, else you'll get it rejected by the database table.
4. If the field you had to set is ALSO unique, the current logic of the “isUnique” method will use the same data to make both entries. So it will not only run into a “unique” error for the field you set and actually should run into it, but also the field you were forced to set, since it can't be null. This leads to 2 unique errors which breaks the test.

I currently have 2 possible solutions for this in mind

1. Completely rewrite the logic of the trait to how I thought it initially worked. Make it so that you have to give it an already existing value and it only tries saving once. You can set the other fields to valid fields that ARE unique since you know what already is in your database, so theres only one unique error. Then just assert that it causes a unique error on that field. This isn't such a great idea however because it relies on you already having an entry in a fixture.
2. Keep the logic but implement it so that if the error you're looking for is contained within the list of errors it still runs through. I'm not sure how well this will work since it causes a different kind of error than validation errors.

REMEMBER TO LOOK AT THIS WITH Fabian