DEV Community

José Clovis Ramírez de la Rosa
José Clovis Ramírez de la Rosa

Posted on

I got my first returned ticket on a project. TWICE.

So you're telling me you're pushing code without testing

It's the same mistake from all the times. A seemly easy ticket is assigned to you. You quickly go through the code and recognize that one line that's causing the issue...

The Scenario

I was assigned a task: "The company's URL is not working properly". I first managed to reproduce the issue and saw that the current URL was being appended with some kind-of dot-notation inside square brackets.

This code caught my attention:

<div class="company-details">
    {% if company.logo %}
          <img src="{{ company.logo.url }}">
      {% endif %}
  <h3>Company Details</h3>
  <p>{{ company.description }}</p>
  <ul class="social">

    {% if company.homepage %}
      <!-- NOTICE THE NEXT LINE -->
      <li><a href="[[ company.homepage.url ]]" class="icon" target="_blank"></a></li>
    {% endif %}

    {% for link in company.links.all %}
        {% if link.share_platform %}
            <li><a href="{{ link.url }}" class="icon" target="_blank">
                <img src="{% static images/app/company/background.jpg %}">
        {% endif %}
    {% endfor %}

I quickly noticed the square brackets that were out of context here. I quickly changed the brackets, commit and pushed the code to QA.

QA returned the ticket.

Fixing audacity with more audacity

When I saw the evidence, it seemed like the square brackets were still there. I checked GitHub to see if I pushed the right code, then made a search for all the places where we were using the company's homepage.

Turns out there was a second template where the same error was made. "Okay, this is definitively the issue!" - I said to myself, and yet once again - quickly fixed, committed, and pushed yet more untested code. I was completely confident that this was the issue.

Nevermind me. QA returned the ticket, again.

Doing things right

Turns out this time the company's URL was sending the user back to... the same page. Seeing the ticket being returned for the second time sent me back to the Earth. This evidently wasn't something I could do with eyes closed, so I decided that I would do it the right way this time.

After reviewing the case I found out that company.homepage was a string! There was no url property, so nothing was being rendered. I fixed the issue but this time I entered to the application as a normal user to make sure that it was fixed. Confirming this, I pushed the code to QA again, keeping an eye on it until it passed QA successfully.

TL;DR, always test what you're doing

Sometimes, we might fall under the temptation of making changes and assuring that it will work. You may do it because you don't want to spend time compiling the project, turning up&down those docker-compose services, redeploying your code to Dokku or, like me, simply didn't want to go to your project's company page to click on an URL.

As tedious as the validation process may be, in the long run, you'll waste much less time testing your changes before passing them to QA. They will also keep your QA metrics healthy :)

Top comments (1)

vyzaldysanchez profile image
Vyzaldy Andrés Sanchez

The real gain from this situation would be to understand that assuming while doing software development can lead to errors that could be avoided by always "doubting" the solution until you see it working in different case scenarios that may exists.

Nice share.