In spite of its unappealing name, CRUD testing is extremely important! CRUD stands for Create, Read, Update, and Delete. As any tester knows, much of our testing involves these operations. Today we’ll discuss the best ways to test Create and Read.
The most important thing to know about testing CRUD is that it’s not enough just to rely on what you are seeing in your UI to confirm that a field’s value has been created or changed. This is because the UI will sometimes cache a value for more efficient loading in the browser. What you need to do to be absolutely sure that the value has changed is to check the database where your value is stored. So you’ll be confirming that your value is set in two places: the UI and the database. If you are doing API testing as well, you can actually confirm in three places, but we’ll save discussing API testing for another post.
Testing a Create Operation:
This text field looks similar to the one we looked at last week, but now we know what it does! This is a form to add a user. We’ll enter the first name of the user into the text field and click Submit. Next, we’ll take a look at the Users page of our imaginary application and verify that the new user is present:
And there it is! Finally, we need to query our database to make sure that the value has saved correctly there. In our imaginary database, this can be done by running
SELECT * from Users
This will give us a result that looks a lot like what we are seeing in the UI, so I won’t include a screenshot here.
To thoroughly test the Create function, you can use some of the same ideas that we talked about in last week’s post. Verify that valid entries of all kinds are saved to the database.
Testing a Read Operation:
We actually started testing the Read operation when we checked the Users page to verify that our new user was added. But there is something else that is important to test! We need to find out what happens when bad data is in the database and we are trying to view it in the UI.
Let’s take a look at what some bad data might look like in the database:
In our imaginary application, there are some constraints in the UI for the First Name field. It is a required field, it must have at least two characters, it must have 40 or fewer characters, and it should only have alphanumeric characters or hyphens and apostrophes; no other symbols are allowed. As we can see in our table, we’ve got lots of bad data:
- User 2 has no entry for First Name
- User 3 has an empty string for a First Name
- User 4 is violating the rule that the name must have at least two characters
- User 5 is violating the rule that the name must have 40 or fewer characters
- User 6 is violating the rule that only hyphens and apostrophes are allowed for symbols