A statement that raises a lot of questions by software developers is: should I use Test Driven Development and does it suits to me or my team. If you don't know what Test Driven Development is, it is probably a hard question to answer. Worse, you may think you know the answer but be labouring under assumptions. Let's get some facts straight and clear up any confusion!So what is TDD actually?
People preach TDD as a God and it's overwhelming at times. It's so overwhelming that you can wrongly interpret it. When you are a starting software engineer it's easy to think that you have to do it all the time while learning programming. Nothing could be further from the truth. When you're just starting your development career you are trying to make things work. Why should we encourage people to stumble through something that doesn't really help them do that? What is our goal as software developers? It's by far not creating the best test suite. You don't get any trophee for that and it certainly doesn't imply you've designed and maintained a great code base. However, when you envolve in your development career and you face bigger and complexer applications, building test cases could literally safe your ass.
So what is TDD actually? TDD stands for Test Driven Development and it's a cycle. You write a very simple test and that simple test will fail. Then you write as little code as possible to make the first test pass. When you've done that, you write a slightly more complex test case that fails. You make the slightly more complex test pass with, again, as little code as possible. And around and around.
So we have three different things:
1. Confidence - By using the TDD approach you will be fearless and it will give you more confidence while developing your application. We have been all there: you make this enormous cool feature. Three months later, you have to modify or extend your feature with new functionality. Depending on how your code is made, this might be stressfully since you don't want to break any existing code/features. Having these tests will give you more confidence since you can run your tests after making new features to see if your tests will still pass. (and you features will still work)
2. You are actually slowly building some documentation - When documentation is written well, it's very useful for other developers or people who are using your code. Proper tests will also stand for documentation. Anyone who has to make a change to your code, will see a list of all valid and invalid inputs/states. They see the code is being used as it was and how it's meant to be used. This will help other developers to understand your code more easily.
3. You will reduce your debugging time - With a set of proper tests, there are fewer places where bugs could hide. Because every line of your code was put in the right place, it's unlikely to be doing something unexpected.
4. No more waste of code - Because you write your tests first, you will write less unnecessary code. Since you only make code that matches with your test cases.
5. It's fun! - I find TDD fun! The moment your red tests (the failed ones) will turn into passed ones. It gives you the feeling as if someone constantly tells you that you are doing something good. This stimulates me, personally, to develop better tests.
Ofcourse, when we are talking about benefits, there will be always drawbacks. Honestly, I find it hard to find drawbacks. It's fair to argue that it takes more time to get used to Test Driven Development. But is that really a drawback? Time invested in Test Driven Development will pay itself afterwards.
It doesn't increase your development time. Yes, you have to design and maintain both production code and your test cases. But you should do that anyways if you are using unit tests. And this statement isn't: to unit test or not. Test Driven Development is just a cleaner way of producing your tests that should be in every enterprise application.Real world testing examples
We are going to use Vue testing examples from the Vue website. If you don't know Vue, I recommend to learn the Vue basics first. Vue CLI has built-in options for unit testing with Jest or Mocha that works out of the box. Let's create a very simple Vue test and create our component after. We can make many common assertions (here we are using Jasmine/Jest style expect assertions just as an example):
This will make our tests fail. Now we create our component until all our tests passes.
I started this post with a question and I close it by reiterating it. Does TDD suits you? I will let you decide. ;)