Introduction

[00:00:00]
>> Hi, I'm Misko Hevery, CTO at Builder.io. I guess I'm known for this thing called AngularJS. And now I do this new framework called Quick. I guess the first question you should be asking yourself is, why should we test? And I'm kind of curious, from the audience, what you will say?

[00:00:16]
>> Testing confirms that your code works as you expect it to.
>> Okay.
>> And it also enables refactoring.
>> Okay. You know why I test, because I'm lazy,
>> [LAUGH]
>> And it's not a joke. I'm kidda serious about this particular thing. I want you to kind of think of testing as the path of least resistance, right?

[00:00:41]
Testing isn't something that, it's extra thing. It's not a good hygiene of, you should brush your teeth cuz it's good for you, but really nobody wants to do it. You should think of testing as actually, it makes my life easier. And to get to that point of where it makes your life easier, we'll talk about it, how do we get there.

[00:01:00]
But on the end of the day, you wanna get in a situation where doing the easiest thing is actually the right thing, right? So you wanna set up your environment, you wanna set up whatever you need to do in order to have the situation where the easiest thing to do, the most lazy things to do I can get away with is actually the thing.

[00:01:22]
>> We have some responses from online if you want me to read.
>> Yeah, yeah, go for it.
>> Testing reveals problems.
>> Yeah.
>> Enables more stable, maintainable code base and scalability.
>> Yep, so I think those are all correct statements. They do kind of fall into this righteousness mode of like, you should do testing because of all these benefits, and these benefits are true.

[00:01:50]
But I wanna also point out that we at the end of the day are humans, right? And we will always do the easiest thing for us. When you're under time pressure and you wanna cut corners and that happens all the time, you wanna make sure that your laziness is your friend and it's actually the path of least resistance.

[00:02:08]
And so people kind of already pointed this out, right? You have all these benefits from improved code quality, increase productivity, team collaboration, confidence, etc. These are all valid things. Let's kind of zoom into some of them, improve code quality, right? You wanna detect your bugs as soon as possible.

[00:02:30]
One thing that I think is important in terms of testing is that you get the confidence to refactor. And I think this is super, super important, right? As the code grows, you start with the best intentions, but it doesn't always work out the way you want. You forgot some constraint or something like that, and so you wanna be able to refactor the code and move things around.

[00:02:51]
And moving things around is scary, especially if it's a code base that is not yours. If you come into a new project and it's a code base that is not yours, you don't know where the swamps are, you don't know where the scary bits are. And so to be able to ask somebody to do refactorings is actually extremely difficult without the confidence knowing that you have tests to cover your back.

[00:03:14]
And so what typically happens is that you come to a project and you're like, I see that there's a problem, I should refactor it. But do I really wanna take that risk of like, I do some refactoring, and as a result, it will make things, I'll have to go and bug fix something forever, right?

[00:03:29]
And so a lot of people don't take that risk, which is actually the complete opposite of what you want, because now your solution isn't the proper solution. Your solution is some hack that you place in place to fix your problem. But actually made the overall problem worse, right?

[00:03:46]
So refactoring confidence is actually a super, super important thing. The other thing is, to me, tests are a form of code documentation, right? We all know we should write documentation, but we also know that that doesn't really happen in real life, right? It's one of those things that we don't ever have time for.

[00:04:08]
But tests are actually, in my opinion, better than documentation because they're documentation that's executable, right? That is verifiable, that you know that is true. And so the way I think about testing is, as a human, right, I can only keep so many things in my head. People say it's about seven things, you can argue what the actual number is, but it's just some small single digit number.

[00:04:31]
And if you can can keep only a few things in your head, then the question then becomes, how do I make sure that I can use those seven things or whatever I have on something useful that I wanna actually make progress in? And so you don't want to use up all of these extra slots in your memory, so to speak, for remembering like, this thing needs to be true about the system, that thing and the other thing, right?

[00:04:54]
You just wanna focus on writing your thing. And so what you do is you take all of these things that should be true, these assertions, these statements about the system, and you codify them in the form of a test, right? So that when you go and refactor or move things around or change things, the tests are there to kinda remind you of saying like, hey, you said that this should be true and this is no longer true.

[00:05:17]
And if you think about it, that is really good point of view from the documentation. Now, the other thing I wanna talk about is team collaboration. If you come to a project and there are no tests, how do you gain the knowledge of the project, right? You will have a really hard time trying to figuring out what things are, and you typically we'll learn by kind of breaking things, which is not useful for anybody.

[00:05:48]
And so to me, tests are a great way of doing collaboration because they codify all of these expected things inside of the test. And so it's a form of communication. You can point people to do it. Now, let me just pause here for a second, let me back up a second and talk about humans.

[00:06:07]
So one of my favorite books is called Thinking Fast and Slow. If you haven't read it, I highly recommend it. I call it the user manual for your brain. So if you have a brain, you should read the user manual, that's the user manual for it. Anyways, in the book, the guy makes a very good point that humans are not very good about being told generalization and expecting them to know how to apply it.

[00:06:32]
Instead, what humans are really good at is, I'm gonna give you a bunch of examples and then you will generalize it for yourself, and then you will know how to apply it, right? And so what tests are, are actually that. Tests are a whole bunch of examples, where I say, look, it should work this way, it should do this.

[00:06:52]
These are a whole bunch of concrete examples that I'm giving you about the system. And then when you read these tests, then you can be like, I can now generalize it into what the thing is actually doing. The opposite is something humans are not good at, right? So if I just give you a generalization and expect you to come up with examples, that doesn't work.

[00:07:12]
But giving examples and expecting you to come up with generalization is something that does work, Mark.
>> Steven online said, as a team lead in architect, I really feel like the team collaboration gets overlooked a lot. Tests have had the biggest impact on collaboration in my years of experience.

[00:07:30]
>> Yeah, and I totally agree with that. The other useful thing about tests and teams is that a lot of times people need to fix a bug, right? And so the way you can collaborate is, there's stuck, they don't know what to do. And so what you can ask them to do is say like, look, just write me a test that demonstrates this particular problem, right?

[00:07:50]
And then once you have a test, you can actually use that as a way to share and collaborate with your teammates. You can basically take that PR and send it to your team and then says, hey, I'm trying to fix this, how would I go about it, right?

[00:08:01]
It's not some vague thing that is hard to explain. It's a concrete scenario that you can get under a debugger and you can look on thread and so on. So yeah, team collaboration is super, super important. We kind of already talked about productivity, right? But mainly the thing I wanna show you and we will talk about as an example is that, you wanna be in a situation where tests are so easy to write and execute that it is by far the simplest thing for you to do, right?

[00:08:33]
This is the scenario you wanna get yourself into. And if it's the simplest thing for you to do, of course, you're gonna do it because it's the path of least resistance. Now, as far as confidence goes, yeah, that is the obvious things of reducing the risk, better user experience, peace of mind, etc.

[00:08:49]
But I really wanna point out the importance of feeling like you have control over your code base. What I mean by that is just the importance of knowing that you can go to your code base, move stuff around, and come out victorious, right? Because the last thing you want is to just go in, try to fix something, and instead of fixing it you get punished by breaking everything.

[00:09:13]
And you either cannot push it to production or worse you push it to production all hell breaks loose. And now you wanna roll it back, but you can't because other people have put stuff on top of it. It's a situation you don't wanna get into because it will just destroy your confidence to do something in the future.

[00:09:28]
So in order to have a malleable piece of code base, you really wanna have tests. And tests, as I said, are form of documentations, but it's also a form of essentially just generic statements of what should be true about the world. And more of these statements you have, the easier time you're gonna have with the tests.

[00:09:49]
And so I'm gonna hammer this down over and over again. But the biggest thing is you need to set up your environment so that writing and running tests is easier than running the application. And there are many situations if you think about it, if I wanna run an application, that's actually kinda tricky, right?

[00:10:08]
Because you have to launch it, you probably have to have some database somewhere. Now you are probably on the login screen, you have to log yourself in, get to a specific page like a settings page where you wanna find the bug. You push a bunch of buttons, something breaks, you need to get it on the debugger, then you wanna change some piece of code and you go back in.

[00:10:26]
And what do you do the whole thing again, you log in, go to the settings page. By the time you recover where you used to be, you kinda lost in your memory what you're trying to debug, right? So you wanna be able to be in a situation where like, hey, let me just write a quick test.

[00:10:40]
Like, I am going to pull up a settings page and I'm gonna do the scenario and look it's failing in this particular way. And then I can debug it and I can go around focusing on a problem rather than focusing on a problem of, how do I get the application in the correct state to demonstrate the problem, right?

[00:10:58]
Because every time you restart the application, you have to, again, go through a bunch of steps to get it into the problematic state, right? And so, again, you wanna be in a situation where, writing the test is actually the easier thing for you to do, right? You cannot force testing on an organization by calling on these high-level things of, like, you're gonna have a better time, or it's the right thing to do, or whatever.

[00:11:24]
Those are all nice, but nothing beats just being lazy. And I kind of talked about it, but let's kind of talk about it some more, which is that, to me, tests really reduce the cognitive load, right? Because they minimize the number of things I have to keep in my mind.

[00:11:37]
If something needs to be always true, and I can demonstrate it in form of a test, that means I can no longer have to think about it, right? And as I create more and more of these tests, there are fewer and fewer things I need to keep in mind because if I break one of those assumptions, the system will tell me, right?

[00:11:54]
And that's really what it comes down to because as humans, there's limited number of things we can keep track of. And the other thing I kind of wanna point out is that a lot of times in organization, things go bad. And people tend to have this thing of, let's blame somebody or let's blame something, right?

[00:12:13]
And people often come to be like, you didn't do this or x or something like that. And I think that's not useful. Because at the end of the day, you can't have a million things that you expect the developer to do, that's just not scalable. At some point, you should just say like, there's only one thing that the developer has to do, and that one thing is automated, which is running the test, right?

[00:12:35]
As long as the test say it's okay, then you haven't forgotten anything. So you can't have a situation where you put the responsibility of remembering to check the boxes or do bunch of things on a developer because first of all, developers leave and come, so you always have a new influx of developers.

[00:12:53]
But also there's a limited number of checklists that you can have as a developer before this becomes not scalable. And so instead, you really wanna offload this work somewhere else, right? And it comes down to the cognitive load of the developer, right? You wanna make sure that the developer doesn't have to think about it.

[00:13:11]
Or to put it differently, the developer has limited capacity to do stuff, and you wanna make sure that you use as much of the capacity as possible for the problem at hand, which is for the business logic or for whatever you're trying to achieve, right? And you're trying to offload all of these secondary things because the more the developer has to keep in their heads, the less there is left over to actually do useful work.