Testing Q&A

[00:00:00]
>> When would you use a Playwright and when would you use Storybook? I think is the, the gist of it, or at least that's what I'm going to answer. So, with Playwright, you could, by the way, use Playwright with Storybook, and a lot of people do in order to verify different things.

[00:00:17]
But the basic idea of Storybook is, can I treat my components as units and essentially create a unit test for my component? Whereas if you just do Playwright, typically the Playwright runs on top of the end-to-end test, which is the application itself, and because of that the end-to-end test is you're not testing things in isolation, right?

[00:00:44]
So for example, if we go back to, to our example of Chicago, and I don't, there we go, it's running. Sorry, the defaults are okay, if you go to this particular example, it is difficult for us to assert that what's actually showing here is the correct output. Whereas in Storybook, we can instantiate just a component and then give it a data set that we are sure about, in this case bunch of points that we know are diagonal, and we can easily verify visually that like, these are diagonal points, right?

[00:01:28]
So, Storybook is a way of getting your individual components running in isolation, whereas Playwright is just running whatever you want and typically you run Playwright on the whole application, so it's truly an end-to-end test. Whereas Storybook is essentially a unit test for your components, it's not quite unit test because a lot of things are in there, but it's essentially a unit test for your components.

[00:01:54]
>> Have you ever gotten to a point where this kind of mocking scenario that you made gets too complicated and you almost need tests for the mocks itself? Is that like a code smell?
>> Yes.
>> Yeah, how would you handle that?
>> So, this typically happens with legacy code.

[00:02:12]
If somebody gives you a code that you already have and you're trying to mock it out, you tend to create lots and lots of mocks. It is a smell, but it's a symptom of the fact that the code you're trying to test there's too much. And so, the solution I'm not sure if it's feasible for you, would be to refactor the code base to make it into smaller tests.

[00:02:36]
Now, because it's a legacy code base, maybe that might not be a solution, and in that particular case, what you wanna do is you wanna create more intelligent mocks. So rather than having mocks that individually, I have to kind of essentially, if you think about it, inside of our unit test, we are training our mocks, right?

[00:02:51]
So if I go back to, These were our mocks, I believe? No, they were not. Sorry, it wasn't Github, not clustering. So here we are training, right, we are, you can think of this as a training the mark to do what we want, we calling the results at specific order in order to train the output to do what we want.

[00:03:27]
And so this can get cumbersome, and so in that particular case, maybe instead of using mocks, you actually make a your own implementation of the fetch. So that can be then can have many of the defaults already set up in there, or has typical places where you can navigate with expected responses, etc.

[00:03:48]
So the way to deal with it is to create more intelligent mocks for yourself. But like the first level would be, don't write code that depends on two Too many marks, if that is not possible because of historical etc, the follow up would be make your marks more intelligent so that at the end of the day, your tests are still readable.