Test-Driven Development (TDD) Experience


I wanted to share a recent experience about Test-Driven Development (TDD) that I experienced recently that I want to share. The information (i.e. usernames) that I provide are for demonstration and imagery purposes only and are not actual usernames.


Recently at work, I had the opportunity to build a REST web service where it accepted 1 parameter and was a POST REST method. It was a fairly simple web service but was needed to fulfill some business requirements. As I was building the web service, I created an excel spreadsheet of different inputs that could potentially be used for testing and real-case scenarios. I made sure to have valid, acceptable inputs, and when doing proper unit testing, one must include the tests that will fail. Failed tests include inputs that could technically be accepted, such as an accepted data-type (i.e. an acceptable string), then don’t forget some exploratory testing. The web service took an input parameter of a username (35 chars). So some of my tests cases looked like this –

    Username                                 Exepected Result                      Actual Result

  • superman                                       Pass                                        Pass
  • wonderwoman                              Pass                                        Pass
  • 189208                                          Fail                                         Pass
  • !#*($)@                                          Fail                                         Pass
  • [Username of 36 chars]                Fail                                         Pass

There are more types of tests that can be performed but these are the types of TDD I have done throughout my career.

As I pondered my unit tests and the results in this TDD, I realized that I forgot to check the case sensitivity (capitalization) of the request string data. For example, my web service was only allowed to accept a username once and create one and only one row in the database. For example, “superman”, could be an acceptable case. I tried different combinations such as “sUperman” or “SupermaN” and the web service was logging/saving each unique combination, even though the username was still the same. The identification server handles usernames in a non case-sensitive type of way, so “superman”, “sUperman”,and “SupermaN” would be the exact same username. But my web service wasn’t treating them like that but saw them as 3 different usernames.

I was able to overcome this bug by casting the username to all uppercase or lowercase and do a compare in the database by also casting the username to uppercase or lowercase as I was with the user input and was able to keep a normalized, unique username in the database.

These are things to consider when doing quality assurance engineering work. I spent 3-4 years in my career doing QA engineering work and these are the types of tests that separate the better engineers from the novice engineers. It’s this kind of test-driven development that will also save you the embarrassment and headache of potential bugs that could plague your application.

Leave a comment

Your email address will not be published. Required fields are marked *