In this post I want to share a Use Case of the value added of Unit Testing and Continuous integration techniques to ensure the quality of TeamMentor. Therefore, I want to show how easy we can ensure that a feature works as expected.
So, What’s the scenario?
Given the below change password HTML form, the first step is to determine how many test can be developed that we can ensure quality?
Roman provided very valuable feedback here, so we defined the following test scenarios:
- Change_Password_Allows_Current_Password : The purpose of this test is verify that the Change Password functionality allows to enter the current password (is this an expected behavior?).
- Change_Password_Works_AsExpected : This test changes the user password and attempts to log with the new credentials
- Change_Password_Values_Dont_Match : If at the time of performing the password change, New Password and Confirmation password don’t match, then the user should be able to see a message indicating what happened.
- Change_Passwords_With_Weak_Value_Should_Fail : If the new password is weak (only numbers for example), an error message is displayed
- Change_Passwords_Length_Is_Invalid : If passwords length is less than 8 characters (or white spaces or empty values), an error message is displayed.
- Current_Password_Not_Valid : At the time of performing the Password change, the user should enter the current password he is using, if he provides a different password, then an error message is displayed. By the way, in this case the error messages is Failed to change password.
- Change_Password_Dont_Validate_FormFields_Length : This test evaluates if there are or not HTML constraints in terms of the length of the form fields.
So more or less these are the scenarios we identified. Note that the first test Change_Password_Allows_Current_Password was designed to be success by design,even when this is a wrong functionality (because the process should not allow to enter the same password or there should be a password policy for that).
Once all test ran successfully in TeamCity server, I sent an email asking if that was a valid case (it had to be changed after the Password hash were addressed). So we ended up with a fix was required. This is the email I sent asking for that :
But just after this issue was addressed, the Unit Test failed, the below image was taken from Nunit GUI.
Why the test failed anyway?
I personally like this real case because I can explain what happened and it is quite interesting. In this case, the Test started to fail until the code was fixed, so note that if the code has changed then the Unit Test is affected.This is also known as traditional testing. Using this example we can verify that the issue was fixed, but now we have an error in our Test.
New approaches like Test Driven Development (TDD), are quite different from traditional development because the life cycle is different , please see the below graphic I’ve created to explain this flow.
In this approach the first step is to write a test that fails, then the code is written and or refactored to make the test pass. This is another way to develop Test cases and it could be implemented.
Can we ensure a project success with TDD?
I’m reading The Art of Unit Testing, an interesting book written by Roy Osherove, so page after page, paragraph after paragraph, I been getting involved in the best practices of Unit Testing. Trying to answer this question, Roy wrote:
It’s important to realize that TDD doesn’t ensure project success or test that are robust or maintainable. It’s easy to get caught up in the technique of TDD and not pay attention to the way unit test are written: their naming, how maintainable they are…
I wanted to share a the real life use case that explains how important is to create a culture based on Unit Testing, even when you can’t ensure the quality of the products by relaying 100% just in this technique (there are many elements that are part of quality), it is a key element in the Software Development and it is helping TeamMentor. We will need to discuss if adopting TDD would be good for us.
I hope you find it interesting.
The Art of Unit Testing, with Examples in .NET, Roy Osherove 2009.