Should I do an integration test for such an edge case

Question

The NAME field of a sql table is a composition of other fields:

1_2_UserId_CreationDatetime eg 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...

Answer 1

I would test it. How the exception occurs is irrelevant to some extent. The usage pattern of your system could change over time.

For the record, you may be violating first normal form , and if you are, I advise you abandon that approach unless you put a lot of thought and analysis into it. I would have to see the full table. If those other columns are in the same table, then you definitely are. You can either add the unique constraint across those multiple columns, or potentially use those columns as a composite primary key (if that is really your intent). You may also need to move some of those fields out into other tables. I would really have to see your design to be certain.

Answer 2

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.