The NAME field of a sql table is a composition of other fields:
1_2_UserId_CreationDatetime e.g. 1_2_domain\Elisa_15-07-2012 08:30:57
My NAME field has a Unique Constraint to express that equal names are not allowed. The primary key is an auto inc id.
Does it make now sense to catch an UniqueConstraintException when a new datarow is inserted but actually its not possible to have the same name twice because then a user must be logged into the web application 2 times and press the button in the same second etc…
Should I really test such a scenario ?
Update
Thats the workflow:
A user creates a new testplan by choosing from a list of templates And release.
Then the testplan is saved with the releaseName_templateName_UserId_CreationDate
But in the 4 fields the releaseId, templateId, UserId and CreatedDate is saved.
To show the user as a NAME the releaseId and templateId (both are int`s) does not make sense.
Therefore I save the NAME with all 4 part_names.
Another design alternative to this composite NAME field could be to remove the NAME field from the Testplan table and when I load all testplans I try to get the releaseName and templateName for every releaseId and templateId.
What do you think? Well please also remember my origion question about the edge case…
The way you’ve described the test it sounds like the test would simply test that the RDBMS is functioning properly–not something you really should be concerned with (if the RDBMS doesn’t work, you user another). Either that, or you’re testing your schema. I’m not really sure there’s much value to this. If the unit test fails, what do you expect to do? Will you verify the schema is correct and if it is, then what? If you’re performing many other tests to validate the schema hasn’t been changed to expected values then a test like this might make sense. If not, it doesn’t make much sense to me.
Now, if your application handled this UniqueContraintException and did something specific, a test to verify the application performs expectedly makes sense.