Videos → The Future of Test Driven Development

Introduction0:00

Hello

So, today I don’t speak in Thai, right? So, English, Y’all understand English, Right? Okay. Okay. So, let's switch.

What is TDD (Test-Driven Development)?0:18

I will talk about TDD, right? So, test-driven development. Okay. So, every time I say TDD, it's really about test-driven development.

Understanding the Audience's Testing Experience0:30

but first i have a couple of questions for you for me to understand what is your level in term of testing first, right? so if you can just raise your hand if you understand the question so who knows about unit tests?

Oh wow, not a lot.

Speaker Introduction and Background0:49

So who skipped the unit test?

Okay, now it's more.

So who knows— who's using Jest a little bit? Okay, a little bit. Okay.

Who knows about the mocks? Mock, mock. No. Oh, one. Okay, good. Smaller and smaller. We'll see.

Who already tried test-driven development?

one over there, two, okay.

Hello, okay.

Speaker's Work Experience and Interests1:42

All right,

so, oh, okay. All right, so what about me? So I'm Olivier. I'm French, but in English, I'm Oliver.

I have 2 children.

I work in a couple of countries, USA, Poland, also Singapore.

In terms of work, so now I'm working at FWD in innovation, but I also worked as engineering manager and also technical coach for different companies.

My main expertise is about API, domain-driven design, test automation, and continuous delivery.

And I'm passionate about Rocket League, so I don't know if there is some good player of Rocket League. And I'm also passionate about open source.

Open Source Project: RestQA2:53

When it comes to open source,

I build a test automation framework. So it's online now, called RestQA. It's more focused on testing microservices, so you guys can check.

Agenda: Why Testing Matters for Managers3:08

All right, let's talk about the agenda. Agenda for me is to share with you as a manager why the testing is important.

Because... Many talk is about technical, technical, technical. The technical needs to serve a purpose.

And this is why I will share as a manager how we can understand unit test, what is test-driven development, and how you can set it up for yourself.

Very important for you as a manager, every time I interview an engineer showing me that he's doing test-driven development, 100 percent of the time, I will hire him. So this is why this presentation is very important for you guys.

The Importance of Unit Tests: A Use Case4:00

So first is why do we need unit tests?

Let's take a very simple use case where we need to measure the room, size of the room.

Thank you. I think it doesn't like people speak English here.

Yes. Okay, so most of us will just... Oh, sorry. Let's go back. We'll just create a small function like this, and we ship production, right? And sometimes, some of us will just try to write the unit test to verify. if our function is working. So for the people that don't know unit test, it's really we try to write a function that will check if this.

It's really good. Okay.

So everything is working. We are happy. We can party. We can go home. It's okay.

How Unit Tests Enable Refactoring5:13

Now, let's say I have a new engineer coming in the team.

He wants to change a little bit the code. Okay, why not? So we run the test. The test is still working. That's perfect.

And then changing again because he prefers arrows function, you know, preference. Some developers like to change. And one refactor again.

One-liner. This time we have a bug, right? And this is the new engineer. And this is me crying because we want to go home instead of trying to debug.

But what happened is... the new engineer tried to put an object instead of a simple parameter.

So the unit test breaks, and this is why we need to have unit test to tell us something is wrong.

The Purpose of Unit Tests: Refactoring Without Business Impact6:20

But what I'm trying to explain here, it's the main purpose of the unit test,

right? It's not to verify the code.

The technical part is to verify the code. But as a company, what we want is to make it refactorable without impacting the business.

Because as a manager, I will have a big team, and I want everybody in the team to be able to go in the code and change everything they want without having some bug in production.

Yes, that's starting to be a bit complex, but let's try to slow down a little bit.

Examples of Refactoring Scenarios7:09

When I say refactoring, refactoring means we can change the library.

Instead of using Axios, we want to use Fetch. It's okay, no problem. It can be a language change. Instead of using the whole JavaScript, now we want to use TypeScript. It's okay. We can still make it happen. Or it can be a data change, right? So instead of database, we want to get the data from API. It can happen. Or now we can have code generated by AI. So our code basically needs to change a lot,

right? From the day we write it. and the day we use it until today it can be a lot and a lot of changes

How TDD Enables Better Refactoring7:57

so this is why I want to explain like how TDD really help us to make a better refactoring.

Writing Unit Tests First: The Key Challenge8:09

That's a lot. Okay, so first,

We need to write the question. And this is what is the most complicated for all of us, is how we write the unit test first. Because the unit test has to be the question we have for the code. This is a simple question I ask. I want to generate a PDF.

Example: Generating a PDF Report8:38

So what I will do, I will just... Oh, sorry. Every time I messed up. I will have my content.

I have my function which is create PDF report and after I'm just checking that the PDF exists.

Very very simple.

Best Practices for Writing Unit Tests9:00

It has to be based on the requirements,

easy to understand, so as you can see it's only a couple of lines.

We try to avoid technical words because technology changes a lot.

function from the business stay the same so we try to use business words and we try to avoid the mock so that's what we need to do first

Writing the Code After the Unit Test9:26

writing the unit test so this is the question i have and after — only after — I can start writing the answer which is the code okay and what's going to happen for example

Example: Maintaining Code Over Time with TDD9:43

We write the code in January 2022, the first version of the code.

But in April, we discover we have an issue with Windows. So we change a little bit the code,

but... The test is still passing, so we can keep changing the code, but the function stays the same and we still have a good unit test.

When it comes to one year later, we discover that the report is getting bigger, bigger, bigger, bigger. So we need to change again the library. So instead of using pdf.js, I try to use pdf. Instead of using pdf, I use pdf.js. Very simple, small change. The unit test is okay. It's still working in production, no issue.

And then another year later, we discover that pdf.js,

which is open source, is not maintained anymore. We have a lot of security issues, so we need to change again. So I can change very easily again just by changing a couple of lines, right? And all of my logic It's still okay because my test is very simple and tell me that your logic is still working.

Refactoring and Its Importance for Managers11:06

And this is what I call refactoring and this is what is very important for me as a manager is to ensure like when my engineer needs to change the code he knows that he will not break something.

And things gonna change for sure, as we saw, this code base is three years old and for sure we had to change. the library many times.

Okay.

Getting Started with TDD: Practical Steps11:35

Now, how do we start? Because this is the high level part, but let's try to find a little bit of action to start.

Because now the key challenge is how we write the question so the unit test from an easier and a faster way.

Stop Using Jest for Backend Testing11:55

The first thing I want to say to all of you is like first stop using Jest. Okay. Because Jest is when you do npm install, it's a lot of dependency coming in that we don't need. Okay. Most of the time we need to have very small test. And Jest is good for front end. But if you do back end, you don't need it for sure.

Using Node.js for Testing12:17

Instead, you can use node --test

So this. is a function from node 18 that you can directly run the test inside Node.js.

So same for the jest --watch, you can have node --test --watch

And the way we use it is exactly the same, right? We go from importing the library and just writing the test.

The only difference with Jest is like you need to do an import. and it has all the same functions as Jest like assert to check your results,

description and even the mock but we don't want to do mock but it's okay.

Setting Up Your Development Environment for TDD13:06

Alright so that's for the first part so that's the easy part.

Second part is how we do

TDD on the computer. Basically, we need to split the window in three, very simple, where we write the question on the left, the answer on the right, and we keep having tests running on the bottom.

Of course, if you have a lot of tests, it can be slow, but nowadays with a good machine like the M1, M2 from Apple,

It's a lot faster.

All right.

Challenges of Testing APIs and Solutions13:50

Now, one of the key challenge when we do the testing is, of course, when we have API. Because if you have an API that need to call line or that need to call

GitHub, it's very annoying when you test.

Stop Using Axios, Start Using Undici14:05

So that's why my first recommendation, again, is stop using Axios and start using Undici.

So what is Undici? Undici is a new... HTTP clients that's been built by the Node.js core team actually.

It has a lot of performance compared to Axios. So as you can see here in the example, it's very simple. We just need to do a request and that's it. But that's not the part that is interesting us. The most important part is how we write the test.

Again, because we don't want to call GitHub when we run the test. And we don't mock as well.

Intercepting Requests with Undici14:52

So what we're going to do, we're going to intercept. What's the intercept? It means every time in the test, you will create a mock agent. and you will say to that mock agent that if you see a request going to GitHub as a get,

you want to reply 200 foobar.

So it means now you can directly test your function without having to mock all the libraries.

So that makes your code a lot better and easier to refactor.

Benefits of Undici for Testing15:31

The other good thing is Undici can intercept requests from other libraries, so from Axios, from got, and so on. Okay.

All right.

Mocking MongoDB with TestContainers15:45

Another one which is very hard when we do tests is how to mock MongoDB because,

of course, when we run application, we have data inside, right? So there is a very good library called TestContainer.

I don't know if you guys know it, but that's changed a lot the game in time of testing.

What test container? So basically every time you run the test, what's going to happen? It will use Docker to spin up a small container.

It could be Postgres, Kafka,

Benefits of Using TestContainers16:20

Elasticsearch, MongoDB, or anything you want, right? Run the test, connect to that container, run the test, and after destroy that container. So that's for me was like mind blowing because now we don't need to mock anymore the connection to any of this system.

I don't know if some of you already worked with Kafka, but testing Kafka is really annoying. But once you have this, it's becoming a lot easier.

So that's why the way to do it is just like in a couple of lines like this.

20 lines where we just. Run the container MongoDB.

Then we directly get the information about our container, the IP and the port. And then we can start writing our test. So we inject data in the container.

We run our business function. And we check the results.

Flexibility in Choosing Database Clients17:23

So it means now,

if I want to write the code using... the official MongoDB client, I can. Or if I just want to change the library and use Mongoose,

I also can. My test on the left will still be okay. It will not have any issue. So now I know that I can go in production with the old or the new client.

Testing with Different MongoDB Versions17:49

Another good benefit is, I don't know if it happened to you, but on your machine you have MongoDB version 8.

and the company is still using the version 6, right? But a lot of functions are different. So what you can do when you use Test Container, you can ask Test Container to run your test on different versions of MongoDB,

so it will ensure that your test is good enough for every version as well. So that's very important.

Using AI for Test-Driven Development18:21

Okay, so now let's talk about AI.

Actually... What I just want to say about AI is today, all of us is using AI to generate some code, right?

ChatGPT as the Best Partner for TDD18:35

But most of the engineers I see is using it the wrong way, right? Because if we understand correctly what I try to say,

ChatGPT actually is the best partner for test-driven development. Because when you write the test first, it means you ask your question first. And what we try to do every time is to ask... question to ChatGPT, right? What is this function? Why is this is not working? Why, why, why, right? So that's the same thing, actually. If you write your test first, you will write a very good question for ChatGPT.

So the test is becoming the question.

Unit Tests as Prompts for ChatGPT19:16

So then it means like… the test is becoming the prompt.

And as we just saw in the previous presentation, If your prompt is very well defined, you will have a very accurate answer. So that's why if you use ChatGPT to generate code, you better put your test in ChatGPT and ask ChatGPT to give you the actual function.

I do this a lot. Then I don't need to write the answer by myself and get ChatGPT to get the answer for me.

Conclusion and Key Takeaways19:49

Okay. So.

In that case,

conclusion.

This is a very advanced topic, but again, like I said, once I have one engineer talking to me about this, for sure I will hire him.

Because an engineer that understands this concept

is an engineer that's building the code that I need in my company to stay for a long time.

Mocks vs. Interception20:28

then it's an engineer that will understand that the mock are the biggest enemy so we mock as less as possible so we try to intercept instead of mocking.

If we have a dependency, we intercept the dependency but we don't mock.

Using AI Effectively for Code Generation20:47

AI is good but we need to use it better. If you use it to produce crappy code, don't use it but if you know how to produce very good code I'm happy to have it too.

Practicing TDD with Open Source21:01

The best way to practice TDD is definitely to use open source. Because, like I said, I'm running now an open source project, and everything I'm doing inside, I'm doing it with TDD. And this is how I'm able to provide a code that is not breaking when someone tries to use it.

Job Opportunities for TDD Practitioners21:23

And, of course... Test-driven development will get you a job easily. So for the one that's already using it at work, I will be happy to talk to you to offer you a job right now.

That's good for me. Thank you very much.