TDD: Write Quality Code, One Test at a Time

Imran Khan — Sun, 03 Sep 2023 18:29:02 +0000

Why even test code

Building software is not like constructing a building where you build it and just forget about it. A software has to keep up with new feature requests, bug fixes, latest trends, etc. I won't be wrong when I say building and maintaining a software involves a ton of blood, sweat (but mostly tears).

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
— Weinberg's Second Law

Benefits of testing

Confidence
- Well written code helps the team have confidence when making a change to the codebase that this change will not break the system.
Converts business logic to code
- Testing is essentially automatically validating if the software produced fulfils the business requirements or not.
Reduce development cost
- As a software grows, it gets worked on by a lot of people. Writing test ensures that every change is approved by the requirements and non-compliant code is blocked right at the source.
Detect failures before they even happen
- Testing helps detect issues even before they reach the end user. This helps improve the quality assurance from the team as bad code is not shipped in the first place.

This is why testing your code is more important than ever, and TDD (Test-driven Development) helps us achieve precisely that. TDD is key practice of Extreme Programming that enables software engineers to have some degree of confidence that their code will work as expected in production.

How does TDD work

As stated by Robert "Uncle Bob" Martin, TDD uses the Red ⇨ Green ⇨ Refactor cycle to write code. The goal is to keep the code changes as short as possible by writing the minimum amount of code while maintaining the existing functionality.

Let's see the actions involved in each step:

Red
- Write a failing test.
- No production code should be written before this step.
- Ideally, you should have only one failing test at a time.
Green
- Write just enough code to pass the test.
- Future scenarios should be avoided in this step.
- Prematurely optimizing your code here would introduce unnecessary complexity and might diverge your intent.
Refactor
- Criticize and refactor the code.
- Refactoring the code should not have any effect to the test result.
- As no one is good enough to write the working code and the most optimum code in the first go, optimizations should be reserved for this step.

Benefits of TDD

Clarity of intent
- As you write the purpose of the production code first, in the test in the form of a failing test, you have a clear intent of how the code should behave.
No unused code
- As the Red ⇨ Green ⇨ Refactor cycle requires you to write only as much code as necessary to pass a test, you avoid writing code for scenarios that might never happen.
Less debugging
- Since ideally, all the scenarios will be tested while testing and development, there is little to no effort spent on debugging
Easier to maintain
- As all the components are tested in an isolated environment, a component's inner working can be changed completely while keeping the input and output same.
Saves cost in the long run
- As TDD makes us write tests before writing any production code, these tests stand guard against breaking changes, thereby reducing possibility of bugs and enabling timely delivery of software.
Immediate feedback loop
- Since you write the tests first, any code that does not contribute in fulfilling the business requirement is discarded at source. This helps you keep check of useful and useless code.
Tests document the code
- Though documentation itself is a very important aspect of software engineering, tests could be a very good starting point stating how the software is expected to be used.

So, with the knowledge of TDD (Test-driven Development), will you choose the blue pill and go back to continue making buggy software or will you choose the red pill and start creating better tested, extensible and maintainable software.

Evolution from Programmer to Software Engineer

Imran Khan — Sun, 27 Aug 2023 18:32:16 +0000

Aren't those two synonyms. No, they're not. A Software Engineer is the superset of a Programmer. Let's dive deep into how exactly they differ.

What's the difference

Well, a programmer is generally someone who's good at creating stuff through the means of code. When they get a specification to create something, they start writing code with a certain use case in mind. This is not much of a problem when you are working in smaller teams or building projects of your own. However, the moment you start working on projects where a good number of teammates are involved, you'll quickly find yourself under a big pile of code because to change one thing, 5 other things need to be modified.

A software engineer on the other hand, will question themself at each step of the process, ensuring that anything they change will be understood unambiguously by the next person who happens to encounter this change.

There are no steps set in stone that one could follow to transition from a programmer to software engineer, but one can inculcate the following qualities/habits that are often found in good software engineers

Think solutions, not code

The most recurring mistake programmers do is immediately think in terms of code when presented with a problem. This approach does not scale well because there are a lot of black boxes at the early stages of any project. These black boxes might introduce features that could render your approach unusable.

Hence, it is crucial to think in terms of entities, their responsibilities and the flow of information between these entities.

Start small

To think solutions, start by approaching the most basic version of your problem. This will enable you to eliminate majority of the known and unknown variables alike from your solution.

Tackling your problem in isolation allows you to focus on the core components of the problem. Create a solution for this version then incrementally keep on increasing the set of requirements and rinse & repeat.

Docs come before code

The importance of documenting a solution before attempting it is arguably the most important step in developing a project. Practices like dry running approaches and writing pseudocode are worth the overhead that they bring to the table.

As any programming language has its own set of rules and limitations, changing documentation is so much easier than changing code.

So next time, before you jump straight to coding a solution, try writing the approach first and you might find issues early on that might have stayed hidden for weeks.

Note: This is an extension of the Rubber Duck Debugging technique.

Set goals

No, I'm not talking about setting up long term goals like a motivational speaker. Setting up goals in the short term means to just write your intent.

People don't realize that just writing down the next 3 steps that you want to take resolves so much of the indecisiveness and introduces a ton of clarity to an approach.

It does not matter if the approach you tried out failed. You just checkout off one method that you thought would've worked from the "approaches" list. Be willing to start with a clean slate and better understanding in case things go sideways.

Be your first reviewer

Always be critical of your solutions. Just because you wrote it, does not mean you should assume it would work in a certain way.

Think of cases where it could fail and be open to corrections from others. It is better if you spot your mistakes before anyone else. After all, who doesn't want to ship bugless products.

Choose your trade-offs

All decisions in software engineering and by extension in life come with benefits and trade-offs. You have to choose which trade-offs are you okay living with.

So, if you choose a particular technology to work with, be prepared to work around its limitations. If you choose an approach to solve a problem, get ready to meet some unexpected guests down the implementation road.

DEV Community: Imran Khan