Testing Project: Input Field

[00:00:00]
>> All right, so let's go explore a few things as we try to get these tests passing just because I have more horizontal space and vertical space. Normally, I use the terminal but there's a vitest VS Code plugin, and there's a testing sidebar in VS Code, we can actually also see your tests, and that works too.

[00:00:24]
There's a really great Jest plugin as well, either one of those depending on what you're using. So do we have an input field? Now, we have seen this app. And again, in true test-driven development, maybe you would render the component, make each test pass, and then you would know that you had a whole bunch of tests around this thing.

[00:00:46]
One day, I aspire to do that. But generally speaking, I think that test-driven is great for making sure you have tests, but the main value of tests is to continually make sure that something didn't break behind your back, right, or accidentally. And so in this case, we can look for a new item and make sure it's on there.

[00:01:06]
Again, this is one of those tests where if it fails, we know that we have some set of a problem here that we need to kinda go deal with. Ones like this, I think I joked about before. When it came time to actually opening up the pull requests, I might delete some of these, some of them are to kind of get in the zone, if you will, right?

[00:01:29]
And does my test suite work? Is my render function working? How's everything doing? They're mostly to kind of get into a, quote unquote, flow state or something along those lines. We have this getByText, which will find some element that has this text in it. The kind of interesting part is, and we'll see kinda later too, is there's getBy and then there's queryBy.

[00:01:57]
getBy will blow up if there's more than one of that thing, right? queryBy will actually just find the first. There's also get all by, query all by, so on and so forth. This is one of those things where it's like, I mention this now cuz eventually it's going to be a thing that bites us.

[00:02:20]
Just kinda trying to put a narrative arc to our time together here. So we got this place. So if I look over the app, I have a bunch of different options for figuring out what I might choose to do here. Now, I've got this element, it's got a label.

[00:02:43]
That's great, cuz who doesn't like accessibility? It's got a placeholder. Cool, it might even have a test ID, right? All those things are things I could probably find out. And so we can do a number of things in this case. I'm gonna render it, and let's do screen.getBy.

[00:03:06]
And you can see some of the different options here, we've got the AltText, DisplayValue, LabelText, that could be useful, or PlaceholderText. Either one of these will work in this case. Part of this and these are all, I want to single one. Part of this is also in the large app that you're working on, what's less likely to change?

[00:03:27]
You know what I mean?
>> Yeah.
>> Maybe this is off topic, why is there not a getBy ID or class name like you would have in the dom?
>> Yeah, I mean, Jen, the class name one, I think we talked about it a little bit, which is like, that's just expecting, yeah, the by style issue.

[00:03:45]
The ID one, I don't know, right? The IDs also have semantic meaning, we've got the test ID. I think it's trying to force you into best practices, right? And there are ways to do it, but generally speaking, I think about that all the time. I don't actually know insofar that.

[00:04:05]
I will also say when we get to playwright, you're gonna see some of these selectors again, right? So there was probably some thought leadership that went into that decision. So we've got a bunch of options here. What do you know we're thinking? We wanna do placeholder or label.

[00:04:17]
Which one? What inspires us right now?
>> Label.
>> Label, cool. getByLabelText, let me go glance at that UI again, it's called New Item Name. I feel like I like that answer, that's probably the right answer. I like having to do a by label cuz it means that you actually had to put an ID on that input field and an HTML "for" and actually make it accessible, right?

[00:04:43]
It's mostly forcing you into making good choices on the implementation side rather than the perspective from the testing side. So I mean, if I save this test to kinda reiterate where we're talking about before, even if I save this test, it's still valuable. Because it's a nice kind of smoke test to make sure that this thing is on the page, this thing rendered the way that I expect it to render, so on and so forth, right?

[00:05:11]
Some of these tests, even without an expectation, can still provide a certain amount of value in your application, right? Because yes, and if this was a full on course just like on unit testing, I think we'd be a little bit more disciplined about few things. But sometimes I think when you have a large other maybe and we get to playwright stuff, you'll see how we can do some really fast stuff to get some test coverage.

[00:05:35]
That maybe is not gonna win you awards for best tester on the planet, which is definitely an image I'm gonna make later. But sometimes it's about, even if you had breath instead of depth, right, how quickly can you get as much of your app covered as possible so in case you need to do that upgrade or changing?

[00:06:02]
Sometimes it's not about having the best tests in the world, it's about having at least a thin layer of problematic tests everywhere is maybe step one. And then you can figure out, okay, what are the most important places, and fix that up a little bit, but sometimes it's about put out the fire first, right?

[00:06:21]
And so even some of these real quickly are decent, and you could probably whip up a bunch of these for some of the, either squareliest or highest traffic components in your app. There was this rails performance app called Skylight, and it was like, the way that would bubble up we needed to focus on was I believe the term was agony, right?

[00:06:46]
Which was how slow is it and how often is it hit in production, right? Because suddenly, it takes 20 seconds to load, obviously, 20 seconds, the browser is terrible, 20 seconds is still bad, and nobody goes to. Maybe it's not as bad something takes three seconds to load as on the homepage, right?

[00:07:04]
And so I think that's usually a kind of interesting part of where you choose to dedicate your time and energy. So theoretically, if it has an input field with this label text, I am technically not wrong in this case, right? I can say this is basically what I would have wanted for myself as well.

[00:07:30]
So this make sure it's on the page, I think I've spiritually fit what this test was asking me to do. Now, again, and I will say this because some of these are just to kinda get yourself started, would I keep this one forever if I had this next one, or if I had the ability to add one onto a page?

[00:07:51]
Honestly, even to that point about what is the user's perspective, the user doesn't really care if there's an input field for adding an item, they care if they can add an item, right? And so you might choose to get to a point where you're actually testing the full implementation.

[00:08:05]
I used the term end-to-end not in the testing term, but closer to the full experience. But again, if you're starting with an application that maybe doesn't have great test coverage to begin with, sometimes it's about even a high-level just set of things to kinda make sure that nothing is totally falling apart.

[00:08:25]
We'll get you there faster than trying to do everything right all the time.