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
What should happen when we view the Users list in our application? That will depend on what the product designers decide. They may choose to display bad data as long as it is not a security risk, such as the First Name for User 6, which is actually a Stored XSS attack. Whatever the rules for display are, it's important to test that those rules are respected.
You may be saying to yourself (or a developer may be saying to you), "Displaying bad data won't be an issue, because we are putting good validation in place to make sure that bad data won't get in the database to begin with." While this is absolutely standard practice today, there will always be cases where bad data will slip in. I once tested a PATCH operation where phone numbers could be inserted into a record. I discovered that while validation was taking place when the PATCH body was formed correctly, there was an edge case where a PATCH body was formed incorrectly and accepted without validation. Any developer that incorrectly coded the PATCH operation could inadvertently allow bad phone numbers into the database!
A good rule of thumb for testing any Create and Read operation is to assume that anything can go wrong and test accordingly. We'll continue imagining what can go wrong next week, when we test Update and Delete operations.
No comments:
Post a Comment