#Wait! What is TDD?

So, you keep hearing about this TDD thing and want to start using it but have no idea why. Don’t worry, the internet to the rescue! But first, what is TDD?

TDD stands for Test Driven Development and is a way of writing code. It means that you first write your test, you see it fail and then you write the code that makes it pass. This is also called the red-green approach. Long story short, it’s Development Driven by Tests.

Small example: Let’s say you want to write a method that adds 2 numbers. Now, instead of implementing the method, you write the test first:

Only now, you know what the problem is, so you can implement the method:

Now, that’s quite satisfying, right?

So, this does a few things:

Makes sure your code is tested, so you don’t have to spend the last 2 days of the sprint writing tests for all the code that you wrote( which never happens )
Makes sure you write code in a pragmatic way. There is a thing called YAGNI(You aren’t going to need it) which is about developers over-thinking and trying to solve climate change and world hunger with the next bit of code. Safe to say, most often than not, this makes the code overcomplicated without any real benefit.
When you finished writing a feature this way, you saw all the tests pass, that gives you confidence that if/when you refactor if the tests are still passing, then you didn’t break anything. How often were you afraid of breaking the product with your simple Pull Request? Feels something like this:
Last but not least, it’s all about the colors! Seeing colors makes us happy. Seeing something failing and then passing, makes us even happier.

3 months and 500 tests later, we have a real sense of confidence over the product that we are building.

The keyword here is: CONFIDENCE

#Now, back to Angular and our component

So, now you have an idea about what TDD is. Next stop, using it in our component. For this post, I am assuming you have a basic understanding of Angular, so I won’t go into details on how it works.

I’ll be using Jest for my tests but the principles are the same.

For our example, let use a fictitious app that lets us create lists with movies. Now, somewhere in space and time, we decide that we also want a page where a user can see his/her favorite movies. So, without further ado, let’s build it!

First stop, let’s generate the component:

ng g c favorite-movies

Now, this will generate a component. So, let’s see, what do we want to do first? We want to add a title like Favorite movies. Let’s do it!

WAAAAIT! What did we discuss? Write tests, then write the code that fixes it.

So, what would that look like? Something like this:

Pretty cool right?

Now, in order for this to work, you don’t need to implement the service. It just needs to exist and have a method that is called getFavoriteMovies.

#Wrap-up

I know, I know, lots of words. I tried to be as succinct as I could without omitting any important information. Easier said than done. This is my first Medium article, so, I’m still learning. Hopefully, in the next one, we’ll talk about testing an Angular Service. TDD of course.

Hope you have enjoyed this program 📺. See you in the next one!

If you liked this article, eh, maybe follow me on twitter: