Why TDD & Tips for Learning

[00:00:00]
>> Francesca Sadikin: Just a little bit of a recap, why do I think test driven development is something that everyone should focus on. You saw changing code is just safer. You don't have to worry. As I was making mistakes like syntax issues or logic issues, I just looked over to my test suite and immediately told me, nope, that wasn't right.

[00:00:21]
I'm like, okay, got it, let me look, right? It leads to simpler solutions. You notice that I didn't pre plan a ton of the code? I was just focusing on one little bit at a time, and then once I saw an opportunity to refactor, cuz I saw like, duplication happening then I made that move.

[00:00:43]
This usually leads to simpler code. It's easier to solve because you're breaking down a problem into smaller pieces, and then it's also less bugs, which makes sense, right? Because you have an immediate signal every time you introduce an issue, you only just wrote five to ten pieces of lines of code.

[00:01:05]
You can easily figure out where in that five to ten lines of code you just added the problem.
>> Francesca Sadikin: I do wanna say that I think tests are powerful if you do it right. But, what you will see in the workplace, in true engineering companies, is that everyone knows that they're supposed to do it, but no one actually does it, or they're not [LAUGH] enthusiastic about it.

[00:01:38]
It's like kind of like this pain in the butt that they have to just check off when they do their work. And I think that a lot of these places are actually just doing [LAUGH] it wrong, and that's why it's so painful. Some of the reasons are because the tests were written as an afterthought, right?

[00:01:59]
So if you write code, there's like all this old code, they have no test, sometimes when you try to add code afterwards, it's just very, very complicated because that code wasn't written in a way to be tested. And so you have really complex tests that are also very brittle trying to inject itself into this code.

[00:02:25]
I think that a lot of tests are also testing the wrong thing. It's testing implementation details. So, this is kind of covered together with the test coverage percentage. I think people get very caught up with, hey, I wanna write tests. Let's make sure that we have over 80% coverage, or it's about a number, but you've gotta remember that tests are meant to serve as a signal whether something is broken or not.

[00:02:52]
And so if you get overly focused on just writing tests for the sake of writing tests, and you're adding all this stuff without really thinking is this actually useful? It is like a burden for other engineers to maintain all of these tests, right? The worst ones are, for example, you are testing implementation details, which means that if someone refactors that code, all of these tests are breaking.

[00:03:20]
But the functionality still works, right? Over time, engineers are going to start ignoring those test signals because they're not actually saying anything useful.
>> Speaker 2: If you can get TDD mandatory on a software development team, would you still need a manual QA team.
>> Francesca Sadikin: I think so. I'm just thinking about, like, how my company works right now.

[00:03:50]
We have a lot of tests, but the QA are also working with us as a partner to think about edge conditions that we may not have considered.
>> Speaker 2: Yeah, I answered that, which is yes, of course, you need it, but it'll make their job much easier.
>> Francesca Sadikin: Easier, yeah.

[00:04:08]
>> Speaker 2: Constantly not having to look for regressions as you're adding new features, because your team has proper tests in place.
>> Francesca Sadikin: Yes, and I think the common mistake here is also thinking that if you have QA, you don't have to think about tests as much cuz you're gonna give that responsibility to them.

[00:04:25]
I think that's a mistake. I think engineers should also think about as many conditions as we can and then partner with the QA to identify more.
>> Francesca Sadikin: So, tips for learning Test-Driven-Development. It's harder than it seems, right? I remember the first few months trying to learn test-driven- development.

[00:04:49]
The hardest thing was breaking the habit of trying to pre-plan your code. I think, when a lot of us are learning how to code, someone somewhere has taught you to think of all the edge conditions. Think about a set of code that will solve all of it, pseudocode the whole thing, write the whole thing.

[00:05:09]
Test- driven- development doesn't do that. It is literally like, you take a single condition write about a bit of code for that and you do that. There is no pre-planning Involved. And it's just going to take you some time to practice test-driven development to the point that you feel confident in that process and you can let go of your urge to plan everything.

[00:05:36]
Also, as the code gets more complex, the test also gets more complex. You have codes that rely on all these other systems. You need to be able to write test suites that can insulate this code and not be affected by all of these external things that are constantly changing.

[00:05:58]
And so the testing approaches and the techniques that you need to handle more complex code, it's quite difficult. Test-driven development, just like any skill, just takes practice. I really recommend that this is something that you can start now with the code that you're writing currently. Try to start small, just like start writing some unit tests for different functions, and over time, you'll notice that you may be writing it for larger, and larger systems.