“This Piece of Code works on my PC”. A lot of developers like to use such phrases’ when things aren’t going the way they expect them to be. However, a wise man one day helped and finished the statement by saying … “It isn’t where you stop; it’s where you start the journey of understanding your code.”
The quest for knowledge and understanding why our code isn’t working is one of the common things that unite us in this industry and TDD is one of the materials that can help us answer such questions very well.
It’s amazing how long it’s been since Mr Pritchard introduced to us a fantastic coding technique (TDD) that inspires confidence and encourages simple design. The Bootcamp module focused on answering the question “Can TDD make you a better coder?” and introduced us to the principles of GRASP and TDD.
Despite it being an old concept in modern programming practices, a lot of devs still find it very weird and contrary to their daily norms. Very few of them actually use it frequently.
I’m not going to tell you that TDD is easy. It’s not, I’ve struggled with understanding it as well. But like any form of craftsmanship, the more you practice, the better you become, the faster you get it and I can promise you that the better you become in producing better production code.
In this article, I’ll share with you my journey of trying to comprehend the design process coming from a beginner perspective and battling the normal challenges of any coder learning a new language. I won’t delve into the nitty-gritty, but I will glean over the most vital talking points.
What is Test-Driven Development(TDD)?
According to Kent Beck, this is a software development process that relies on repeating a very short development cycle where a dev writes a failing test that defines the functionality, writes just enough code to pass the test and refactor the code to the acceptable standard.
In a nutshell, there are 3 laws of writing a test;
- First, write a failing unit test for a feature.
- Write just enough code needed to pass the failing test
- Finally, Refactor your code if possible
Like most things in life, TDD is easier said than done. There are many challenges along the path and it’s a huge learning curve. It might seem confusing at first but when you continue and engage more, you will get to know the gift that comes along with it.
There are a few techniques and basic tools you need set up in your local environment before you get started with writing a unit test. The two most core tools are the usual suspects of Node.js and Node Package Manager (NPM).
What you need to decide after this is the testing frameworks you will be using. There is a list of testing frameworks out there but the most popular ones are Mocha and Chai. Recent JavaScript frameworks have inbuilt testing frameworks (Angular has Karma) that you need to familiarize yourself with before you start writing unit tests.
Other testing frameworks that deserve honourable mentions include AWA, Jest, Jasmine and Tape. What will influence your choice of frameworks depends on your ability and willingness to learn something new or what the company you're working with uses. The Fundamentals of writing Unit test remains the same across all domains.
"Test-Last vs Test-First Approach of Writing Test"
There are two ways of writing tests when using TDD to automate your tests for a piece of code i.e. Test-last approach or the Test-First approach.
In the Test-First approach, Tests are written before the features have been developed to make the code pass when you start writing them. This approach tends to reflect the developers understanding of the requirements and most times considered excellent design quality since the tests are written first. They are most likely to be done.
In the Test-Last approach, the tests are written after the features have been developed and testing is done during crunch time since it’s an afterthought.
Once you know the program is working, you write a unit test to confirm the logic and by virtue, it will pass at first try. If it doesn’t then it means there is something wrong with the logic and your program which you need to fix before proceeding.
This was the only approach I managed to grab at the first try (lesson) and I tend to use it a lot more than the latter.
Your decision to choose any of these approaches is a personal call and boils down to your knowledge on the implementation of each approach. I prefer the Test Last approach but regardless of your choice each of them has their pros and cons which you will have to bear with and working in companies the project lead dictates the method or approach you should use in your team. It’s better you equip yourself with the fundamentals for both and like a soldier you’re always ready for war (implementation of the test).
Back to the million-dollar question, Will TDD makes you a better coder?
At the time of jotting down this article, I thought the question “Can TDD make you a better coder?” was the most reasonable question to answer. However, interacting more with fellow developers made me ponder and thought to myself that what we should be really discussing is: “Where and at What point do you need TDD?"
Will TDD help you polish and write more readable code? Definitely. Will it make you a better coder? That’s debatable and will depend on what you're trying to achieve in your coding career. For Junior Devs and people starting out in the craft it’s important you master the basics and fundamentals right at the get-go since it will serve you for the rest of your career journey.
Being a better coder in a production team is a combination of so many little attributes. From following the configuration of linters on the dev environment to understanding version controls of the team you’re working with. The key is to adapt to the team you’re working with and deliver the task demanded of you.
You can be one of the best programmers ever but the moment you fail to sync with the team you’re working with, you can be considered a dead weight and burden to the team.
And one more thing, TDD isn’t for every program or piece of software you write. It’s most suitable for production codes and companies with an already well-documented codebase where mistakes aren’t an option and the cost of failure is way too vague.
Top comments (0)