Whose responsibility is it to test the code you write?
I get this question in my mind so frequently these days. Having been part of various projects, I got a chance to interact with many senior developers. Without commenting on their knowledge level, all of them had one thing in common – they did not know how to or did not want to test the code they write.
I get this question in my mind so frequently these days. Having been part of various projects, I got a chance to interact with many senior developers. Without commenting on their knowledge level, all of them had one thing in common – they did not know how to or did not want to test the code they write.
Is it too difficult to perform basic unit testing? No, it is
not. People simply verify the happy path testing and release their code for
testing team. They forget to include some small but crucial negative scenario,
which if encountered can generate high priority defects. Then follows the
meetings and several mails from managers and clients as to why code failed in
Production.
So, I just thought of putting down some scenarios that
should also be verified before releasing the code, especially if your code
might be accessed in different browsers.
1. Testing input fields on the form
a. What happens when only spaces or value with leading
& trailing spaces are entered – to check if you need to code the trim()
logic.
b. What happens when special symbols having special
meanings for browsers are entered? Example: hash (#), apostrophe ('), ampersend (&) etc. – These become
even more crucial, when these input values are used as querystring and sent
through the URL. Some Browsers like Firefox will consider their special meanings
and break the URL flow.
c. When user enters the value with caps lock ON? –
Sometimes, the values entered are correct, but only because their case is
different than what you have coded, your logic fails.
d. Input fields having regular expression validation
like Email, must also be tested for above combinations, although these are
relatively safer and less prone to bad input values.
2. Testing navigation related scenarios
If your form allows user to select some values and then navigate away and return, it becomes important that your code retains the user-selected values on return. For example: You have an online shopping website and user has selected to view items in descending order of price, from a particular city and in a given price range. When user moves from one page to other, you need to retain those preferences.
If your form allows user to select some values and then navigate away and return, it becomes important that your code retains the user-selected values on return. For example: You have an online shopping website and user has selected to view items in descending order of price, from a particular city and in a given price range. When user moves from one page to other, you need to retain those preferences.
3. Database and Screen field length Testing
Most fields on an input form are mapped to a database column. In many projects with large teams, these are coded by different individuals. Chances of a mismatch in coded values are more. Thus each field should be validated for its maxlength (maximum allowed character limit).
Now, do you think these should not
be part of Unit level testing and it should be a developer’s responsibility to
validate at least such scenarios instead of waiting for a Testing resource, who
may have more than one project to handle, to identify such flaws in your
coding.Most fields on an input form are mapped to a database column. In many projects with large teams, these are coded by different individuals. Chances of a mismatch in coded values are more. Thus each field should be validated for its maxlength (maximum allowed character limit).
