I don’t like TDD
TDD. Understanding the reasons your project needs it.
A handful of weeks prior to writing this article, I spent time asking the questions of whether I should implement TDD on the projects I was planning on developing. In the process, I ended up creating a tool that made automated tests… life is weird like that. As a preface to the reader, I will be diving into the benefits of this tool when discussing my solutions to implementing TDD in future projects.
Test driven development is a topic accompanied by stifled groans and as a result, this article is divided into two parts to remedy said rhetoric. To skip the reasons why and get a summary of the best ways to add TDD to any project, scroll to the very end (look for Tools and Solution). For everyone else, let’s take a look at two distinctly different scenarios…
Project 1:
There is a highly complex and dynamic code base being worked on by developers in different time zones. You have the front end team discussing issues with their state management, the backend team disagreeing with dev-ops decisions, and the marking team is trying to talk to the graphic designers while they’re creating files that need to be adjusted to fit in the current codebase.
You may not have worked in a scenario like this, but it’s clear if anything goes wrong, the entire ecosystem will suddenly be crushed. TDD is definitely required when dealing with so many moving parts.
Project 2:
A simple codebase is written for an open source Google Chrome extension. One person - at most two, are working on coordinating backend and frontend changes. The app is used by a good number of people and provides a service that is constantly being improved.
This project is probably similar to the scale of most production projects and we arrive at the conclusion that maybe it’s not entirely necessary to deal with things like TDD
“What do we learn from these examples?”
Test driven development is about creating the logic and response of functionality as tests before implementing them into the application. The flow that is generally used is as follows:
When a basic functional test is implemented, the developer refactors the code and continues the test until there is an error. The idea behind this logic is to create a solid, concise codebase that is purely working on the things that are required.
In our aforementioned projects, the first example seems obvious when considering implementing TDD. The second, however, is generally the most overlooked. TDD isn’t just for large codebases. It serves as a tool to accurately identify errors and test the logic being implemented in the application. As a result, this code not only becomes more readable for future developers, but it also reinforces skills for the person implementing them.
“Ok I’m sold, how do I begin?”
Implementing TDD is easier than ever!
There are a plethora of applications that provide automatic test creation and others that streamline testing libraries with concise documentation. For the sake of readability and time, I will focus on an endpoint test automation tool “eeQL.” Its purpose will be to simplify endpoint testing. I will also provide a list of technologies to dive into if you’re interested in expanding your scope in the realm of TDD.
Tools and Solutions:
“What is eeQL?”
eeQL is an endpoint test creation suite that removes all of the unnecessary time spent writing individual endpoint tests. It has a built-in interface that accepts both RESTful and GraphQL endpoint queries. The application has a UI friendly testing module input form that takes the information when submitted and automatically creates a test file within the uploaded project.
At the current moment, eeQL has support for OSX. There is more information and details on how to use eeQL on the website.
~
“What are some technologies I should look into when trying to implement TDD?”
Testing and using current open source tools generally depends on a solid understanding of Jest, Supertest, Enzyme and Puppeteer. Taking the time to understand these technologies and tools will provide you a better outlook on how to implement tools in the future.
In conclusion, if you’re provided with an ability to reinforce your knowledge, build safety nets for functionality in your app, and allow the frameworks for future scalability and onboarding, there is no reason not to implement TDD in everything you do.
eeQL has been made possible by these developers
To support the project or contribute visit our github