I recently tweeted:
A new test sequence: CRUDCA: Create, read, update, delete, create again. — Because sometimes an object can’t be again. #software #testing
I got some feedback from this, so let’s present the idea in a bit more detail.
Many systems know these 4 basic actions for an object:
- Create
- Read
- Update
- Delete
That’s where the abbreviation CRUD comes from. In many cases that’s also a rather typical test sequence to check whether the system can handle these actions. — And often it’s also good enough testing.
But sometimes there are more restrictions at work:
- An object may only be created once and only once. It may be removed, but then not created again.
- It must be possible to create an object with identical properties again and again.
This is how I came up with ‘CRUDCA’: Create, read, update, delete, create again.
Obviously, it depends on the particular (business) context whether or not it is allowed to create a certain object. The ‘create again’ part covers the action of attempting to create the object. The expected behaviour comes from the requirements or specification of the system.
If you want to expand it further, I guess you agree that you want to test Read also after you have done Update, Delete, and Create Again.
CRURDRCAR!
You’re right — but then: Why stop there? In some cases it may well make sense to go though a lot more steps, entering the area of long sequence testing.
In my opinion it doesn’t make much sense to name a specific sequence such as CRURDRCARUURRRURURUDCAUUURUR.
In the concrete situation in my project we expected an object to be ‘re-creatable’ after being deleted, when it wasn’t. This wasn’t a failure that occurred only after a long sequence, but every time we tried to delete an object and then create a new one with the same properties.
So the problem wasn’t related to a long sequence, in fact CDCA would have been enough (not that this sequence would have made a whole lot of sense business wide in our context).