Test-first – Drive Clean Code with Automated Unit Tests

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 havea 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.

You sit down at your desk, you read the requirements, and within a few seconds, you’re writing your first line of code.

With every minute that passes, your algorithm matures into a solution, and you are confident it can handle all the edge cases.

You lean back to inspect the result. Yes, that is beautiful, self-explanatory code. You can almost hear how it speaks to you.

You call your colleague over for a code review. He looks at your code for a few seconds and drops his jaw. Then, he turns his face to you, smiles, and asks: “Can you show me how you did that?”

There is, in fact, such a killer skill.

It’s called…

Test-first Programming

Test-first Programming (a.k.a. Test-driven Development or TDD) is a counter-intuitive but fun practice that lets you solve any coding problem step-by-step with clean, elegant code.

At its core, the practice boils down to these 3 simple steps:

1. Write a simple test

2. Make that test pass

3. Clean up the code

Wash, rinse, repeat.

“How do you eat an elephant? One bite at a time!”

A SAFETY NET OF TESTS

Mostdevelopers approach programming likefree solo rock climbers – they code without any safety equipment.

I think that’s funny because:

Mostmountaineers approach climbing likeTest-first Programmers – they don’t climb without safety equipment.

When a free solo climber slips while climbing up the 3,000 feet tall wall of El Capitan in Yosemite National Park, that’s it. No more climbing. No more anything.

The majority of professional mountaineers, however, use ropes and create anchors along the way.

When they slip, they don’t usually fall to their death. Instead, they only fall a few feet until the last anchor catches them.

Writing tests as you navigate your way toward a solution is a bit like climbing a mountain with ropes and anchors.

A mountaineer climbs a mountain step-by-step and installs anchors along the way.

A Test-first Programmer solves a problem step-by-step and writes tests along the way.

When a mountaineer faces a difficult stretch of wall, they can be confident that the system of rope and anchors will catch them.

When a Test-first Programmer faces a difficult requirement or some code that needs to be refactored first, they can be confident that the safety net of tests prevents them from breaking things that worked already.

A mountaineer sometimes gets tired. Or they miscalculate a move, lose grip, and slip. No problem. They get caught by the closest anchor. Then they rest, reflect, and try it again.

A Test-first Programmer sometimes doesn’t see that changing this one statement doesn’t work for one edge case. The corresponding test starts to fail. So the Test-first Programmer reverts the last change, reflects, and tries it differently.

With Test-first Programming, you can even pause solving the problem at any point in time. Then, when you come back the next day, you have a set of tests that tell you exactly where you left off.

And as long as the tests pass, you can be confident that your solution works as expected. No more slipping back.

“TDD is like having a ratchet that lets you save your progress, take a break, and make sure you never slip backwards. That way you don’t have to be smart all the time.” ― Harry Percival

Introducing…

TEST-FIRST

A one-of-a-kind online program that gives you the complete system to driving Clean Code development with Automated Unit Tests.

In this self-paced online course, you will learn Test-first Programming – a high-in-demand development approach that is so much more than just writing tests.

Test-first is full of actionable advice, techniques, and tips that will get you started in seconds and make you write code that works. You will learn how to approach complex problems confidently and refactor your code into clean, elegant solutions.

No more getting stuck for hours. No more guessing around what to do next. Your peers and managers will appreciate the high quality of your work.

HERE’S A SELECTION OF WHAT YOU CAN EXPECT

• The complete system to solve any coding problem step-by-step

• A technique to get started in seconds – even if you haven’t understood all details of the problem yet

• How to turn lousy tests into maintainable test cases that tell a story

• 50 Refactoring Patterns you can use on a daily basis to keep your code clean

• Watch me refactor a complex algorithm step-by-step and learn to apply the methods in your everyday life

• The secret to uncovering missing test cases so that you will always know what to do next

• How to use Test-first Programming to impress managers and your peers

• 9 Practice Challenges with solutions to help you reinforce and fine-tune your new skills

• And so much more…

WITH TEST-FIRST, YOU WILL LEARN HOW TO…

Approach problems with confidence

Requirements can be confusing. By approaching complex problems test-first, you will be able to uncover a solution step-by-step. Instead of being scared of working on new stuff, you’ll be excited to pick up a new challenge.

Get started in seconds

Too many requirements can be overwhelming, and we often struggle with finding the right starting point. In this program, you will learn how to get started within seconds, even if some of the requirements are still unclear to you.

Always know what to do next

Sometimes we get side-tracked or lost. With Test-first Programming, you will get stuck less often. I will show you a system you can use to uncover the next steps. You will stay on track, and you will altogether get to the solution faster.

Create code that works

Writing a test first makes you think harder about the problem you are solving. This significantly reduces the chance of introducing new bugs. You’ll also build a safety net of tests that will protect you from breaking things.

Write clean, elegant code

Test-first Programming is not just about writing tests. It’s about creating elegant solutions to your problem. Refactoring your code into a self-explaining clean solution is built into the system.

Impress management and peers

Testing skills are in high demand, and your fellow developers will appreciate the high quality of your work and even ask you for support when it comes to writing tests.

HOW TEST-FIRST IS DIFFERENT FROM OTHER TDD COURSES

Most developers struggle with or have given up asking the following common questions:

• What test should I write first?

• Have I missed something?

• Is that a good test case?

• What should I test next?

• Is that actually good code?

And most courses on test automation do not provide answers to these questions. The result is that developers give up on writing tests.

And even if they write tests after implementing a feature – they will end up with a less elegant solution. Over time, the codebase will become a nightmare, and developers will not enjoy coding as much as they used to.

In this program, I provide answers to all the questions above so that you can actually enjoy writing tests, be more productive and, as a result, be more satisfied at work.

IT’S NOT JUST ABOUT WRITING TESTS

Our primary goal as developers is to solve problems for actual end-users.

And with a Test-first approach, we can divide these problems into smaller ones and tackle these easier problems one by one.

But Test-first Programming is not just about solving problems and writing tests.

Every minute we spend on writing code also comes with 10 to 100 minutes spent on reading code ― reading code of other developers and code we’ve written ourselves in the past.

Our secondary goal must therefore be to write clean and maintainable code.

“Code is read 10-100x more often than it is written.”

For instance, having to dig through files with hundreds of lines of code slows us down – and it is super tiring. But refactoring our code regularly will save a lot of time in the future when something needs to be changed or fixed.

And here’s the good news:

Test-first has Refactoring built-in

Test-first Programmers refactor all the time. It is not an afterthought. That’s why in this program, you will not only learn how to write tests but also how to clean up your solutions.

If refactoring has always been somewhat intangible for you, you’ll love this course. I’ll cover 50 Refactoring Patterns and Clean Code Principles, and I’ll show you how to apply them.

HOW DOES TEST-FIRST WORK?

Test-first is an online course that will allow you to master Test-first Programming in your own time and on your terms.

You don’t need to be a senior developer to master Test-first Programming. Everyone can learn it!

I’ve actually seen junior developers producing better solutions in less time with a Test-first approach than senior developers trying to solve the same problem free-style without writing tests along the way.

“I’m not a great programmer; I’m just a good programmer with great habits.” ― Kent Beck

The curriculum of Test-first is structured into 10 sections – each taking you a step closer to becoming a Test-first programmer:

Section 1: Get started

In the first section, we will ensure you have everything you need. We will set up your code editor and the runtime environment.

Section 2: Drive the Code

Once everything is set up, we will shine a light on how to write tests before writing any production code. Learn about fundamentals like the Red-Green-Refactor Loop and the 3 Rules of TDD.

Section 3: Ease into that first Test

Especially the first test is tough for most people new to Test-first Programming. Learn how to turn the first test into a no-brainer and finish it within less than 5 minutes.

Section 4: Uncover hidden Test Cases

Once the first test is written, we often struggle with the question: “What to test next?” In this section, we will get some unexpected help from ZOMBIES. They will help us identify missing test cases.

Section 5: Make a good Case

In the next section, we will learn how to distinguish lousy test cases from good test cases. Then we will use Equivalence Partitioning to figure out whether we have tested enough.

Section 6: Sound like a Test Native

Tests are about expressing expectations. If your vocabulary is limited, you will sound like a fool. Learn how to use Matchers right and start sounding more like a pro.

Section 7: Refactor like a Senior

Refactoring is built into Test-first Programming. This section will explore a few clean code principles and refactoring patterns that will help you write better code.

Section 8: Get more out of Test-first

In this section, we will explore more advanced test framework features that will make your test-driven life easier.

Section 9: Succeed with Test-first

It takes only 5 minutes to understand the 3 rules of TDD. Yet, most developers who try Test-first Programming give up after a while. Here, we will learn how to avoid most of the common anti-patterns and succeed with Test-first.

Section 10: Master the Coding Exercise

Have you ever considered using Test-first Programming for Coding Exercises? You should! Learn in this last section how to get the most out of doing Coding Exercises.

THE JOURNEY IS THE REWARD

Test-first Programming is an incremental process and impossible to master by just studying the final code. This program comes with over 6 hours of carefully edited videos that will allow you to follow every step of the test-driven thought process.

In Section 2 – Drive the Code, you will find a little sneak peek. You can watch the lecture “Test Hello – Round 2” right now.

AND THAT’S NOT ALL!

Every section also comes with the following:

Cheat Sheets

I’ve created handy cheat sheets for you to download. Use them as a quick reference while you are taking your first steps as a test-driven developer.

Menus

Sometimes you have many options – and when you need to pick one, none comes to your mind. Take refactoring patterns, for instance. There are just so many things you can refactor. With the Menus I’ve added, you can see all your options at one glance, pick one, and dive right into a more detailed description with helpful examples.

Practice Challenges

Test-first Programming is a rewarding skill that requires practice. That’s why I’ve added tons of coding exercises for you to reinforce the techniques learned in this program.

HERE’S WHAT PEOPLE WHO HAVE BEEN THROUGH THE BETA PROGRAM SAY:

“I finally managed to secure a position as a web developer. Later, I found out that I got the job because they were impressed by my testing skills. They wanted ME – a junior developer – to show THEM how to get started with writing tests.” — Dominika

“I consider the ZOMBIES technique my biggest takeaway from David’s course. After applying TDD in my work, I could feel more safe and secure that any changes I make are not breaking existing functionality in my application and this feeling is a huge win.” — Judit

“I’ve done multiple online courses to teach me how to write test first, but most of them just cover Red-Green-Refactor, and I continued to struggle with writing tests at work. This course gave me not only an answer as to what to test first & how, but it also opened my eyes with regards to why writing tests last sucks so much. Hands down the best TDD course you can find online.” — Eric

IS TEST-FIRST RIGHT FOR YOU?

This course IS for software engineers of all levels with and without previous testing experience. The motivation for taking this course, however, will be different depending on your individual situation:

Test-first IS for you if…

You’re struggling with solving coding problems

Successful developers do not cook up working solutions in their brains. No, they solve problems systematically – one step after another.

Test-first is a system that was invented for precisely that purpose. And everyone with some basic programming experience can learn it.

Learn how to divide a problem into smaller chunks and solve these more digestible problems one at a time.

You’re uncertain if your code changes are any good or free of bugs

Are you 100% sure that your code works? Can it handle all the important edge cases? Is your code clean and maintainable? Are you confident that you didn’t break anything?

If your answer to any of these questions is not a clear YES!, you will benefit from learning Test-first Programming.

You’ll learn how to build a safety net that will give you confidence that things work as expected and protect you from breaking things. And you’ll learn how to refactor your code into simple, self-explanatory solutions.

You planned to get into writing tests anyway

That’s perfect. Test-first is actually the best way of learning how to write tests. You can start fresh and not have to unlearn bad habits. You are like a raw diamond that waits to be cut and polished.

Trying to test existing code that is not written with testability in mind is actually the worst-case scenario a developer can face. It’s super hard. Learning to write tests by writing them first is much easier.

You’re already struggling with writing tests

Do I need to test that? What should I test first? What should I test next? Is that a good test? Have I tested enough?

Many developers hate writing tests. But writing tests can actually be fun – if you learn to do it right. Most of the problems developers have with writing tests originate from writing the tests after finishing the feature.

Write tests first, and everyday obstacles around testing will simply disappear.

You already tried writing tests first and gave up

Most developers who gave up Test-first Programming never learned to do it properly. Usually, it is bad habits and anti-patterns that need to be blamed.

Give Test-driven development another chance and learn how to do it right. Learn how to write testable code. Learn which tests are required and which aren’t. Learn how to write good tests that make refactoring easier rather than harder. No more discussions about code coverage. No more: “I still need to add these missing tests.”

Test-first is NOT for you if…

You’re looking for an overnight solution

Test-first is a combination of techniques that require practice. You will not master Test-first Programming by just watching the videos. That’s why I’ve added tons of practice challenges. I recommend you invest at least 2 hours per week (more if you can).

You struggle to understand the code block below

What you’ll learn in this program is independent of any programming language. But you should be able to read simple code written in a C-family language. In this program, we will be using basic JavaScript. You will be fine if you’re familiar with C, C++, Java, Python, Swift, Objective-C, PHP, Ruby, or any similar language.

You’re simply looking for a tutorial on how to use test framework X or Y

This program is not about a specific library or framework. Yes, you will learn how to use many of the features that come with most test frameworks. But that’s more like a side-effect of learning how to write tests first.

Test-first Programming is a development approach that goes way beyond just writing tests. It’s about writing clean, maintainable code that works. The incremental process involves continuous refactoring as well as deliberately applying software engineering principles.

WHAT TYPE OF PROGRAMMER DO YOU WANT TO BE?

In the end, it boils down to the question of who you want to be…

A Free Solo Programmerwho writes more code than necessary, treats refactoring as an afterthought, and loses precious time debugging silly mistakes?

Or a Test-first Programmer who solves complex problems efficiently step-by-step and continuously refactors the solution into Clean Code?

Are you ready to take your coding skills to the next level?

THEN JOIN TEST-FIRST NOW

FREQUENTLY ASKED QUESTIONS (FAQ)

I just started off as a developer. Is this course right for me?

Yes. Learning Test-first Programming becomes, in fact, harder the more experience you gain without it. With a traditional approach, we tend to think too complicated. But once you’ve rewired your brain with a test-first mindset, you will appreciate how simple software engineering can be.

I have not found a job yet. Should I join this course and learn Test-first Programming?

Yes. And mention your new skill on your CV. I also recommend approaching coding exercises test-first (there’s a whole section about how to do just that). Test automation skills are in high demand. Some of my students could secure a job because they had testing skills, and other candidates didn’t.

Do I need to know how to write tests before joining this course?

No. Writing tests is one thing you will learn in this course.

Is there a difference between Test-first Programming and Test-driven Development (TDD)?

That depends on who you ask. The term Test-driven Development or TDD is a bit overloaded and often refers to writing automated tests in general (not necessarily first). Test-first Programming, however, is always about writing the test first.

Do I need to know any particular programming language?

No. The techniques I will teach you in this course are independent of any programming language.

But you’ll need to bring some basic understanding of procedural programming. You should, for example, be familiar with concepts like functions, arguments, return values, variables, if/else statements, and loops.

We will use JavaScript, a language of the C-family. So if you’re familiar with C, C++, Java, Python, Swift, Objective-C, PHP, Ruby, or any similar language, you will be good to go.

Do I need to know any frontend, backend, or testing frameworks?

No. The concepts you are going to learn are independent of any frameworks. We will learn Test-first Programming using Jest, but there is no need for you to know it already.

Are there any hardware or software requirements?

Yes. You’ll need a computer with an up-to-date operating system capable of running your preferred code editor — everything else we will set up together at the beginning of the course.

How is Test-first different from other courses on the market?

I am not aware of any course that goes beyond the basics. Many developers give up Test-first Programming after a while because they do not fully comprehend how it actually works. They skip necessary steps, repeat common mistakes, and fall back into bad habits. I have observed dozens of test anti-patterns, and I’ve covered all of them in this course so that you can succeed.

I don’t have time. How do I know this is going to work for me?

This course is self-paced, and you’ll have unlimited access. I recommend you invest at least two hours per week into learning Test-first Programming. You will almost certainly not master Test-first Programming by just watching the videos. That’s why I’ve added 9 practice challenges for you to fine-tune your new skill.

I already write tests, but not test-first. Is this course right for me?

If writing tests is painful or cumbersome for you, yes. Writing tests after you finish the implementation is usually more challenging. This is because the code has not been refactored continuously and is often not testable without adjustments.

Our project’s code coverage is pretty good. Is this course right for me?

If writing tests is painful or cumbersome for you, yes. Test-first is not about code coverage. It’s primarily about writing cleaner, more maintainable code that works.

I am not sure if my team would enjoy writing tests first. Should I join anyway?

Yes, you’ll undoubtedly benefit from a system that makes solving coding problems easier. And discovering solutions test-first is less stressful and can actually be more fun.

My team/manager is against writing tests. Should I join anyway?

Yes! And once you have mastered it, tell them how it changed your life as a developer. ALL successful software companies use test automation to stay competitive long-term.

I tried writing tests first and gave up. Why should it be different this time?

Most developers who tried Test-first Programming and gave up could not follow 3 simple rules or fell back into old habits. It’s a matter of discipline and awareness of the common red flags. That’s why I cover 30 common test anti-patterns in my course.

I hate writing tests. Why should that change?

Because chances are good that you’re currently doing it the hard way. Writing tests at the end is one of the hardest things imaginable. The code is not written with testability in mind and needs to be adjusted first. Writing tests first leads to simpler, cleaner code that is much easier to work with.

I heard that TDD slows you down. Why should I learn it then?

That’s not true. With Test-first, you will actually be able to ship more features. There are plenty of reasons for that. You’ll work, for instance, on a much cleaner codebase all the time. Another reason is that you will have to spend less time fixing bugs.

Will this course teach me how to write Unit Tests?

Yes. And you will learn how to tell a lousy Unit Test from a good one.

How long does this course take?

There’s no time limit. You’ll get full access to all sections and practice challenges on day one. It really depends on how much time you’re willing to invest per week. Let’s say you can invest one hour a day; then, it will take you at least two weeks to work through all the material.

HERE ARE A FEW MORE RESULTS FROM TEST-FIRST BETA STUDENTS:

“My biggest win from this course was that I got a solid understanding, a blueprint if you will, of how I can build applications in the future. Also I am now able to better answer questions about testing and clean code in interviews.” — Alexis

“Thanks to David I now know exactly what to test and when I have tested enough. I’ve learned to work my way from simple test cases to difficult ones, which helped me get much faster.” — Alina

“I used to find writing tests daunting. But now it’s not so scary anymore. During code reviews, I can even make useful suggestions on how to improve the tests written by our senior team members.” — Veronica

9 OUT OF 10 JOBS REQUIRE YOU TO BRING TESTING SKILLS

All successful software companies expect their developers to write automated tests. It’s just not sustainable to have expensive developers test the app manually all the time – or worse, to let end-users beta-test the product.

A safety net of hundreds or thousands of automated tests can be executed quickly at any time. This is essential for any team that does not want to lose momentum when shipping features:

And Test-first Programmers are even better off than Test-last Programmers who write the tests for a feature after the feature is finished. The reason is that Test-first Programmers refactor continuously while implementing the feature.

The result: Less code, cleaner code, better tests, fewer bugs. And this, in turn, allows Test-first Programmers to ship more features over time.

NO MORE CHOKING

Remember, Test-first Programming is not just about tests. It’s primarily a technique to solve problems step-by-step.

As a Test-first Programmer, you don’t have to “swallow” the whole problem in one piece (and potentially choke on it). Instead, you can “chew” your way to a working solution one bite at a time.

And you will have to spend less time debugging. Thanks to the safety net of tests, you’ll immediately notice when you’re about to break something. Should you ever take a wrong step, you can just undo whatever you did in the last couple of minutes and try a different approach.

JOIN TEST-FIRST NOW

Rating Distribution

• 1 stars: 1 votes
• 2 stars: 1 votes
• 3 stars: 1 votes
• 4 stars: 19 votes
• 5 stars: 33 votes

Frequently Asked Questions

How long do I have access to the course materials?

You can view and review the lecture materials indefinitely, like an on-demand channel.

Can I take my courses with me wherever I go?

Definitely! If you have an internet connection, courses on Udemy are available on any device at any time. If you don’t have an internet connection, some instructors also let their students download course lectures. That’s up to the instructor though, so make sure you get on their good side!