Test-first - Drive Clean Code with Automated Unit Tests (Udemy.com)

Master the Art of Test-first Programming (TDD) and learn how to drive Clean Code development with Automated Unit Tests.

DOES THIS SOUND FAMILIAR:

Becoming a developer can be very painful in the beginning. And being a more experienced software engineer can still be a frustrating experience (so keep on reading – even if you already have some previous testing experience).

Being confronted with a new programming problem is scary. Some of us even start to panic a bit when we think about our last encounter.

"I don't want to feel like this ever again."

Initially, we have no clue how to start. There are so many details and edge cases to juggle around. So we write a for-loop here and an if-statement there.

Was there not this Array function? We've used it only once in our training, so we open up the documentation and give it a read. No, not this one. Maybe this one...

When we finally get back to our main problem, we realize that we have totally lost track. We struggle to make sense of the code we wrote just a few minutes ago.

So we try to pass a callback here and write another if-statement there...

"NOTHING F***ING WORKS!!!"

After being stuck for hours, we realize there is no way around it: We have to ask the more experienced software engineer for help... again...

The colleague looks at our code for a few seconds. Then he takes his glasses off, puts the index fingers to his temple, closes his eyes, and sighs.

I could hear my OWN code turn on me and whisper: "JUNIOR!!"

From the perspective of the experienced software engineer the whole situation looks a bit different:

We are actually just tired.

We've just finished this User Story that has been dragging on for weeks. Yesterday, we finally managed to weed out all the bugs (that we knew of), but then the damn feature somehow stopped working altogether. We've spent the whole morning trying to figure out why.

But we are not surprised; the codebase of this project is a big mess. Rewriting the whole thing would be nice. But that's never going to happen. Multiple times we asked for a Refactoring Sprint, but just last week, the Product Owner postponed it indefinitely.

Anyway, it's only lunchtime, and we feel completely drained already. But we have to pull through. It's Friday, and we have to ship the new feature tonight.

After helping this Junior, we will have to fix all the broken tests for our new feature. And the continuous integration pipeline will probably nag us again anyway. We will likely have to add a few more tests here and there.

And we will certainly not re-open this annoying and endless discussion about code coverage again.

"I f***ing hate writing tests!"

WHY WRITING TESTS AT THE END IS SO PAINFUL

Most developers write tests AFTER they are done implementing the solution. They write tests last rather than first.

I've been a Test-last Programmer myself for many years, and I know that writing tests at the end is an excruciating process.

By the way, trying to learn how to write tests by writing them at the end is even worse.

Yes, you can pick it up on the job, as most developers do. But:

Learning how to write tests by writing them at the end is actually the hardest possible way there is.

It's like trying to run a 42 km marathon without any prior training and preparation – it's possible, but you will either give up long before reaching the finish line or wish you were dead most of the way.

Here are 3 reasons why writing tests at the end is so painful:

1) The code is simply not testable

The code is usually not written with testability in mind and is untestable without rewriting it first.

One reason is that Test-last Developers have no system that encourages them to improve the solution along the way - before it grows too complex.

And having to work in a codebase where most files have hundreds of lines of code is really exhausting. Sometimes it seems like seniority is defined by: "how long it takes before you run out of battery." Can you make it until lunchtime already?

2) Writing tests at the end is not fun

It's not very encouraging having to add tests when you're actually done with the task. You've solved the problem the hard way already – without the safety net preventing you from breaking things that worked already.

The last thing you want to do now is to write a bunch of tests. You know that your code works. You tested it manually already. You remember well because you had to restart the app multiple times. Each time you had to wait a minute, and you had to click through to the button that triggered the functionality you were working on.

I've never heard a test-last developer say on a Friday night: "Don't wait for me; I'll join you later. I will just finish writing these tests."

3) They simply don't know how to write good tests

Most developers have never learned how to distinguish a good from a bad test.

Often, I see lousy tests that don't provide any helpful information once they start to fail. These tests have poor names, or they test too many things at once.

Many tests are written with the goal of covering as many lines of code as possible – the result: Tests that are tightly coupled to the implementation. Changing or cleaning up the code breaks the tests – even if the algorithm is still valid.

Having to fix hundreds of tests after making some transparent code changes is annoying – another chore. Refactoring is further discouraged. Over time, the codebase deteriorates into a nightmare.

But what if I told you that there is a killer skill you can start learning today?

A skill that - once mastered - can make all the above problems go away...

Imagine you and your teammates standing in a row, facing your manager.

The manager says: "I have a super challenging problem to crack for one of you. Volunteers, step forward!"

Before you know it, all your teammates take a step back. These weasels just volunteered you.

But no problem. You stay super cool. You even smile a bit.