Testing Fundamentals

Accident Counter Exercise

Steve Kinney

Steve Kinney

Temporal
Testing Fundamentals

Check out a free preview of the full Testing Fundamentals course

The "Accident Counter Exercise" Lesson is part of the full, Testing Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Students are instructed to implement the remaining tests in the accident counter project. This lesson includes the solutions for testing "days" is displayed when the count is zero and ensuring the count is incremented when the increment button is clicked.

Preview
Close

Transcript from the "Accident Counter Exercise" Lesson

[00:00:00]
>> Steve Kinney: Your mission is to kind of see roughly how many of these you can get through. I'll remind you that we've got this user event here as well. Just remember if you're using user event, they've got to be async/await, right? But try your hand and if one feels like a stopping point, I give up on it and try a few out and let's see, where pain was felt, where it was easy.

[00:00:29]
And we'll kind of talk about it as a group and then we'll dig into the parts where it hurt and clarify those up, right? Again, this is your first time doing this. No pressure, but we wanna figure out where thes sticking points were, and then we'll kind of hyper-target those, then me expounding greatly in all these little examples.

[00:00:51]
We got a few ones that will be straightforward, and some might present some interesting challenges to us. Were there any, let's start with an easy one and then I'll kinda pose the question, if there's any that were of particular interest as well, but let's start with one that is not too dissimilar from what we had previously.

[00:01:13]
It displays days plural when the count is zero. So one thing I can do, is I was smart enough to make just that word wrapped in a test ID go past me. So give me a suggestion in that case, it says get by text days, that works. In this situation, you could see a world where that becomes problematic, though, right?

[00:01:47]
That's a pretty generic one, I'm gonna go with my Test ID in this case. It is saying that because this is the only element on the page. But you could also see a world where the word days appears more than once on a page. So, I am gonna go with the counter unit that I created.

[00:02:05]
Thank you for the suggestion, testing playground. I will respectfully ignore you,
>> Steve Kinney: Cool, so we've mounted on the page, so I can do, in this case is const unit, I don't know.
>> Steve Kinney: And we can say that we expect that unit.
>> Steve Kinney: Do I have text content, days, plural, all right, three paths in this case.

[00:02:49]
All right, let's try this one because this is the first time we're going to like interact at all with the DOM. Any other fun ones before we do that? No, I mean, we could do these, but let's do this next one. Cool, cool, want to increment when the increment button is clicked, so what are we gonna need?

[00:03:14]
We're gonna need the increment button, and so we can go ahead say.
>> Steve Kinney: And this is where you could set up some stuff in the before each to make it easy to grab these things, I don't know. Generally speaking, every time I have gotten particularly clever with my code in my task, I tend to regret it.

[00:03:39]
Because, again, if you think about the use case in which you are looking at these tests after, like, when you're writing them, sure, sure, sure you're looking at them, right? When the next time you're gonna look at this test is after you write it, when it's broken. And sometimes it's kind of nice just to have everything in one place, right?

[00:03:58]
For instance, we might, just choose to do this in each one of the tests,cuz then it's very clear what component we're looking at, everything along those lines. That is really kind of at your discretion thing, but what I don't want you to do is just be like, well, HESCO in the before each because Steve put it there one time.

[00:04:14]
Steve's not even totally confident, everything's got trade offs, life is hard, everything that was easy and definitely had a rule was either pushed down to the compiler or the framework, you're left with all of the weird trade-offs. What can it be in an engineer? Screen, get by role, button, and there was this one with the name.

[00:04:46]
>> Steve Kinney: Again, this will find case insensitive, you will see that in all of the docs. I'll be honest with you, a lot of times I tend to just put the actual string in there. But you will know which one you come to regret more over time, cool. So we've got that, increments the count when the button is clicked.

[00:05:08]
So I'm also gonna need that count that we had before.
>> Steve Kinney: So we've got that, and so what we could do now is say, await, and this might not work, and we'll talk about why in a second.
>> Steve Kinney: User event, click the increment button, and now we can expect that the counter
>> Steve Kinney: To have text content one,
>> Steve Kinney: All right, this one passes, I am going to talk about a case where it might not pass and why, which is, time is hard, right?

[00:06:09]
There are this one because we're just like, literally changing some state. It was fast enough that it works, but let's say, for instance, you were implementing a search, right? Where person types something in they hit the submit button. It's almost like we have an example of this coming up later, don't worry.

[00:06:28]
They hit the submit button, and it sends a API request, getting the search results back, and it renders it on the page, right? It's not a search box, it's a different box, but it's fine. What could happen in this test is that it goes to check to see if those, like search results are on the page before anything has been rendered right?

[00:06:51]
Which is usually just a problem when you're using some kind of framework that is going to try to, like, wait for changes and then figure out and reconcile how to update the DOM. If you are directly updating the DOM real fast, everything's fine. But if you are theoretically using some kind of framework, you might end up in the situation where you've got to wait for the DOM to re-render, right?

[00:07:16]
And so this one works, but I'm gonna show you what to do if it doesn't, which is for all of the various framework libraries. There is this other one called act, which again, if you remember the three parts of our test, the arrange, the act, also known as the word I forgot earlier, and assert.

[00:07:34]
This is basically do all these things and then wait for a re-render. And then you can go look for things on the page, and there's some other ways we can handle this in a moment that I'll show you. So you could theoretically say, and that will take an async function too.

[00:07:59]
So basically we say, do all these things, wait for the dom to reconcile and then go see if the DOM changed the way that we wanted it to. Again, this is more useful for things that might take a second and have more than one cycle to them. Okay, we had to go hit an API and render it on the page, so if you find yourself like, hey, I stopped watching the course now and immediately jumped into my app to start writing some of these.

[00:08:20]
And then you hit brick wall, this is more than likely the first brick wall that you hit. And so if you get those problems where timing is hard, this will go ahead, wait for everything to re-render at a steady state after the number of things you do in here, and then you will continue along your way.

[00:08:38]
In this case, it works either way, which is a good opportunity shows you rather than letting you find out the hard way.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now