Wrapping Up

[00:00:00]
>> We're talking about this thing and I was kinda hoping to take you through all the parts of it basically. You start with a unit test, you do test-driven development. We did issues that arise with components and being able to mock, and how do you mock things? And then, what you run over kinda tooling you would do.

[00:00:19]
And then we went up from there, said, okay, so let's say you have a component that's actually a visual component, how would you test that? And we looked at storybook, then we went into a playwright, which is end-to-end testing. And there we talked about not just how to test it, but also the importance of having page objects, so that you can use the page objects as a way to simplify the interface to the to the user.

[00:00:42]
Because on end of the day, the thing that matters for the test is not that the test is running, is that the test is readable, right? Because it's a form of communication, it's a form of documentation. It's a form of, if a new person comes into your team you can point them to the test and say, look if you read these examples, your brain will be able to see a bunch of concrete things.

[00:01:03]
And then, you can generalize into what the system actually does and how it does it. And so the main point of this was to show you different strategies you can use when writing or testing your application. And the pattern that was consistent across them all is that you wanna be able to get hold of your dependencies, right?

[00:01:25]
Dependencies is how you make sure that you can unit test it, whether it's dependencies in the form of a unit test or it's a dependency in terms of a database. Whatever level you're testing on, it's the dependencies that allow you to make sure that you don't have too much on hand all at once, and you can just focus on the individual piece.

[00:01:47]
So with that, questions? Mark.
>> So when approaching a legacy code base, would you start with the playwright test and then try to work backwards down to unit tests?
>> Yes, so if you have a legacy code base, you really have only one choice to kinda get started, which is to do the playwright, the end-to-end test.

[00:02:12]
And as you do that, then you slowly figure out ways to say, hey, maybe I can get the database running in the local environment, and I can get some sample database set in there that I can write the test for. Maybe I have a unit test that I need to write.

[00:02:31]
Maybe I can refactor a part of the application. But before I refactor the part of the application to make sure it's testable, I will write a playwright end-to-end test that covers this particular area so that I will not do some kind of obvious mistake. And so you wanna iteratively go at it over time until you have enough end-to-end tests to kinda have reasonable feeling that you can refactor bits.

[00:02:56]
But at the same time, you wanna come at it from the unit test side and verify individual pieces together, and then hopefully over time the application can be refactored in the state that makes it easier to unit test. I think you had a hand up.
>> Yeah, so I have a question about the nested constructor pattern.

[00:03:17]
So the anti-pattern you talked about, constructor within the constructor. So let's say if I have a colleague who doesn't believe in testing, how else would I convince him that a anti-pattern and shouldn't be the way?
>> I think it's, like in my general argument with people is that the code that is testable is better code because it's more decoupled.

[00:03:41]
The example of a house instantiating its bedroom, that's a fixed code, right? You have exactly one kinda bedroom that's in there and there is nothing else that you can do. But if you can pass dependencies in, then you can use the house with a big bedroom, a small bedroom, or multiple ones, or whatever, right?

[00:04:00]
You have choices, and I think you should agree with me that choices is a form of freedom that you wanna have. These choices are helpful because it allow you to do more things. So to me, whenever I argue for testability, the thing I'm really arguing over is that I wanna have a code base that is more flexible so that I can instantiate it in the ways that are useful for unit test, right?

[00:04:32]
And I don't think anybody will argue that having the freedom to configure the system in more ways is a bad thing. Typically, people will agree that flexibility is a good thing, right? You wanna make sure that you can use the same code in a lot of different ways.

[00:04:46]
And so having things fixed and difficult to do makes it kind of hard, right? The other thing is once you write a unit test where you have a house where you inject a bedroom, and so instead of instantiating, you inject it, it is very difficult for somebody to undo that because the only way they can undo it would be to delete your test.

[00:05:13]
Because your test kinda is insisting on look, I need to be able to instantiate this with a fake bedroom. If you're gonna refactor it, fine, do whatever you want, but you have to retain me the right to configure it with a different thing. And so it becomes extremely difficult for people then to do something that is non-configurable because that immediately means that that test that's already written will not work.

[00:05:36]
So once you fight the battle and get one test in that is able to extricate a piece of code inside of its unit test by itself, it is extremely difficult for the rest of the developers on a team to regress, because regressing would mean that they would break the test.

[00:05:54]
And I'm pretty sure that nobody is gonna just blatantly delete the test, right, hopefully, that's not a thing that would happen.
>> Is there a catchy rule of thumb for when to write a unit test?
>> A catchy rule of thumb. Pretty much always, right? [LAUGH] But I'm not sure if I have a catchy slogan for it.

[00:06:14]
>> When in doubt, unit test.
>> When in doubt, unit test.
>> Before you rest, write your tests.
>> There you go.
>> [LAUGH] I like that, PK with a slam dunk, all right. With that, I think we're done. So thank you.
>> Thank you.
>> [APPLAUSE]