How to teach your team to write automated tests?

Are you a CTO at a startup, a tech lead, or a senior engineer on a team full of people who see tests as a needless burden? Are you tired of seeing them debugging the code for hours when you know that two or three tests written before writing the code would prevent the problem? Do you want to teach them how to write proper tests?

Table of Contents

Don’t Call it Test-Driven Development
Don’t Pretend They Won’t Need to Work Hard
You Can’t Teach it

Good. I’m teaching BDD workshops, testing workshops for data engineers, and organizing Software Craft Meetups. Let me tell you what I have learned about teaching people how to write tests.

Don’t Call it Test-Driven Development

For some reason, people are allergic to the term Test-Driven Development. It happens for many reasons.

Some loathe the most vocal proponent of TDD - Uncle B. Fortunately, there are others: J. B. Rainsberger, Kent Beck, Anna Filina, Sandro Mancuso, and others. You can pick a role model without significant character flaws.

Some people point out that TDD is a design technique, not a way to write automated tests. Right. Tests are just a side effect of TDD. That’s correct, but we still end up with tests. For me, it doesn’t matter how you write the tests, as long as you have them and they are written correctly. In this case, “correctly” means avoiding overmocking and having a correct understanding of the term “unit test.” It is not a test for a single function/method! We are supposed to test a unit of behavior and be able to run the tests independently.

Some unfortunate people worked with TDD gatekeepers who told them they were not worthy of calling themselves programmers unless they followed the TDD steps to the letter. I don’t know how you can help those people overcome their TDD trauma.

The term TDD may bring lots of negativity. I mention TDD as just one of the options. I prefer names such as “test-first” or just automated code testing. After all, I am here to help those people, not scare them off.

Don’t Pretend They Won’t Need to Work Hard

Some people attend the workshops passively. They listen to what I say, they look at the screen when I show them how to write something, but they don’t do any exercises. They sit and wait until the time passes.

Usually, I say multiple times during the workshop that we came here to do exercises because they can watch someone else coding on YouTube. For free. Some people leave when I say it. It is fine. The workshop is an opportunity to practice the skills in a safe environment. You can’t break anything. You won’t get stuck because I am there to answer the questions. All you need is a willingness to do the exercises.

If you teach people how to write tests, you will have similar problems. Some attendees will sit and wait until you magically upload the knowledge into their brains. The sooner you tell them it won’t happen, the better. They may leave when you do it. You may feel bad about people leaving your workshop. I see it differently. If people who want to sit for eight hours leave, I have more time and energy to focus on attendees who want to learn. Those who left can watch the recording later. Of course, they won’t do it, but they can.

I had workshops where people told me, “You know, we are not doing the exercieses. Just show us how to do it, we will practice later when we watch the recording.” It is a lie. They won’t do the exercises later. They won’t even watch the video.

Nevertheless, I obliged, and I was glad they told me that. We could waste hours if they pretended they were doing the exercises (it was an online workshop, I couldn’t see them). If they didn’t tell me, I would wait 10 minutes, repeatedly asking if anyone had questions or issues with the exercise. Then I would ask who wants to share their solution with the group. Nobody would volunteer. I would write the answer myself. Show them another exercise, explain it, and repeat the process until “we” finish all tasks. I was happy they were brave enough to admit they came to watch someone coding. That saved us hours. I would be happier if they practices, but I have no control over their choices. Neither do you, even if you teach your employees.

You Can’t Teach it

This brings us to the last point. You can’t teach automated testing. You can show the proper techniques, give some hints, but in the end, they have to do it themselves. It is like learning a new (human) language. You can sit in a classroom all day long listening to a teacher. You can even do the exercises during the lessons and all of the homework. But that won’t be enough until you attempt to use the language in a real conversation when you have half of a second to think about what you want to say and how to say it correctly.

Practicing during a workshop is just a starting point. Signing up is not enough. Paying for the workshop is not enough. Even attending and sitting passively is not enough. Watching the recording afterward and doing the exercises on your own is not enough because you lose access to the trainer who will help you when you get stuck. Also, I don’t believe anyone is watching those recordings.

The only way to learn automated testing is to learn the basics (for example, during a workshop) and practice it at work. Regardless of the testing technique, they choose to follow.

How to teach your team to write automated tests?

Don’t Call it Test-Driven Development

Don’t Pretend They Won’t Need to Work Hard

You Can’t Teach it

Using AWS Deequ in Python with Python-Deequ

How to deploy a Transformer-based model with custom preprocessing code to Sagemaker Endpoints using BentoML

How to teach your team to write automated tests?

Don’t Call it Test-Driven Development

Don’t Pretend They Won’t Need to Work Hard

You Can’t Teach it

Using AWS Deequ in Python with Python-Deequ

How to deploy a Transformer-based model with custom preprocessing code to Sagemaker Endpoints using BentoML

Related Posts

Test-Driven Development in Python with Pytest

Why should you practice TDD?

Testing legacy data pipelines