TDD — Registration Page Digipus Application

Introduction

TDD Cycle

Shortly, TDD is just to code your test first, then implement the code based on the test you made. In my opinion, it is not as easy as it said, because I haven’t code the “TDD way” for a while, and it took time for me, as a programmer, to be familiar with the programming language and its frameworks so I can code the test first and work on the implementation.

Why TDD

There are many references on the internet about the reasons to code the TDD way. But to summarize, there are 3 main reasons that I also felt influencing my working flow.

1. TDD can be our code guard. As the tests tell us on what should be on our code, we won’t code things that shouldn't be on our project.
2. TDD can reduce bugs. As the tests are written based on the cases that will happen in your code, you will reduce the possibility to encounter bugs as the cases leading to bugs are already tested.
3. TDD can act as code documentation. The tests are written as a procedure on how will your program be used, you can basically read the tests, especially if you are planning to refactor the implementation.

My implementation

To make it clearer, I will show my implementation of TDD (not the best practices on TDD, but this is a good start for amateur programmers). This project is called Digipus, a platform to archive soft skills training materials. This project is purely built with Django. In Sprint 2, I was assigned to code the registration page for contributors, who will provide the materials. I will divide my TDD phase into the frontend phase and the backend phase.

Backend Phase

I needed to create tests based on 3 modules: urls.py (routing), views.py (rendering and business logic), and models.py (database). And of course, this test is also coded based on positive and negative cases. The list of tests that I made as follows:

1. The routing tests where I tested the code with existing and non-existing URLs.
2. The function I used to render the registration page.
3. The function I used to mock a user with successful attempts and unsuccessful attempts (incorrect details).

The details on how the tests are written are shown below.

Tests for routing and page rendering

Tests for database and business logic

Now that the tests are made, I already have my guideline on how to implement my code. So here are the implementations of urls.py, views.py, and models.py

Snippet of models.py

Snippet of models.py

Snippet of urls.py

Snippet of views.py

Frontend phase

Now that I’m done with backend stuff, let’s get on to a more eye-catching implementation, the frontend phase. It’s a lot simpler than the backend tests, as you only need to test what should and should not be on your page. There must be a correct title for the page and correct field names.

Tests for content that should exist on the page

Now that I’m done with my test, I can start coding my frontend implementation, and here is the page itself

Frontend implementation

Conclusion

Well, so far TDD helps me a lot. Because as I said on reasons to code TDD way, it guided me pretty well on how to code my page. So if you are willing to stay on the right track during implementing a page, TDD is a very good way to not mess things up.