Intro to React Testing [Jest and React Testing Library Tutorial]

Just another WordPress site

Intro to React Testing [Jest and React Testing Library Tutorial]

yeah I’m Chris Schmitz, like he said I work remotely for a company a tech company had created out in San Francisco and I’m recovering from a stint as a manager and getting back into more of the technical leadership path and one of the big kind of areas of emphasis as I’ve been doing that as has been testing with our team that upgrading our kind of test tooling and patterns and conventions and switching from and I won’t go into this a whole app boat we were using some different tools like enzyme and mocha and transitioning from that to just and react testing library and excited to share some of the things we’ve been talking about here all right so first I don’t want to assume any knowledge about testing here I know especially with the next group with Wisconsin UX so I want to go high level just explain you know really what is what are we talking about here in terms of a test it’s very different from the kind of a be testing we were just looking at and kind of the motivations for why and I feel that testing is is really important testing can actually be a pretty polarizing topic you might talk to people who will talk about automated testing and like writing test for your code and they may be adamantly against the idea of even doing this but some oh this is my perspective and how I think it’s provided value to to me and it seems I’ve been on will talk about the different levels of tests that you can write some of the tools for writing tests and then finally I’ve got a handful of tests that I’m going to go through using code sandbox so these are like a interactive online editor and I’ll have all these examples that I can actually share afterwards to if anyone wants to go back later and play around in the code sandboxes with some of the you know and have although like react and the testing tools set up to so starting with just a definition get it gets make sure we have some shared idea and terminology of what this really is the way I think about a test is just code that I said that we write to verify the behavior of our application sorry there we go I guess another another way that I think about what is the test you know I think about it as we probably all are familiar with gonna click testing going through and manually testing logging into production verifying clicking through the behavior of the thing that I just pushed to production and making sure that it works as I expected some teams have just really big QA teams they don’t have any automated tests and they rely totally on that but this approaches more from my experience relying on the engineers writing the product writing the future code writing their test writing automated tests that we that I think of as kind of like a an army of like little robots that will you know run all these repeatable tasks that you could put ask a QA team to do but then and then anytime anyone pushes any code to production we run all of these you know thousands of tests to verify that everything is working the way it’s it’s supposed to there in our aggressions in the existing code and the the new code that we added is working as expected so jumping into the the why of we should write why I think it’s important to write tests this is a very goo global topic and you’ll find different reasons all over the place but if there’s so there’s a few things that really stand out to me like a few reason things that have really provided me a lot of value around like a good test suite the first one is I feel like tests serve as documentation of how our code is actually supposed to work I’ve been on teams that have tried the document things in every way imaginable but I’ve I’ve in my opinion the closer to the code that the documentation lives the better and the more likely it’s not going to get out of date and stale and if your documentation is yelling at you because you broke it like it’s it’s incorrect I mean that’s that’s and it’s just guaranteed that you’re gonna go and update that so I think you know stepping into a new a new code base or Frank ramping up someone on our team and I think people tend to look at the tests as documentation you look at

the source code and you’d there could be any number of like bugs or use cases you might have overlooked but then you look in the tests and you see oh it’s actually an assertion that this behaves this specific way so this is a feature not actually an oversight or a bug another big benefit here I think is consistency and we’re going to talk today about specific testing react components I think about them as more almost kind of like integration type of style tests but there’s all kinds of different levels of testing like we’ll talk about but I think some of the some of the most valuable tests that that I’ve seen verify that people do things consistently you know that you name your files a certain way and your directory structure is a certain way and there’s a whole set of linting tools and there’s static analysis and all those are really providing the same I think oh those is tests because they’re providing the same value they’re telling me when I’m doing something they’re providing me feedback about my code that I can act on and actually like go from red to green to make make things pass I’ll do it any time I’m shipping I’m like pushing code to production I feel like a good test suite just gives me so much more confidence I mean I really feel like it’s a you know just a nice warm blanket nice very comforting to have this well while I’m working in a code base because I just if without it you know I constantly feel like I’m I don’t know I really feels like the Wild West to me so maybe this is I know that this is a little bit because I’ve I’ve transitioned from thinking well I mean my progression is kind of like I don’t know what testing is became aware of tests am like why would anyone do that it seems like a lot of work to like okay fine enough smart people seem to be doing it John keeps telling me that it’s important all right I’ll read tests and then to the point now where it’s it’s it really is a crutch for me like I need to have the tests there too to really be confident about the code that I’m pushing the production and I think for anyone new coming into a code base if you have a complex system it’s it’s really it’s really nerve-wracking get those first commits out into production and and you know having a strong test suite can really really help people feel a lot more comfortable navigating a code base especially when they’re not familiar with but ultimately I think all this just boils down to productivity and we we write tests because we think it’s gonna make the team or productive and you know that accounts for you know code quality and and all of that over time and there’s definitely trade-offs here so you know if you’re a solo developer you know cranking out like MVP through code that you plan to throw away in six months like maybe there is a value to get tests around that but if you think you’re laying the foundation of a multi-million dollar business and you wanna onboard dozens of developers to help you maintain that codebase in the future like those tests are going to be the foundation of something much bigger and provide a ton of value for a huge huge dividends going forward so I mentioned briefly that there’s different types of tests starting kind of at the the highest level and working our way down there’s end-to-end testing which is almost like a QA person but it’s it’s spinning up actual web server it’s databases in certain records in the database and pull it pulling data out going through I mean literally simulating someone using a mouse and clicking a keyboard that’s that’s what I what I think of when I think about end-to-end testing integration testing is testing where you still have multiple units of that or modules that you’re testing but it’s not you to stand up the whole stack to do that so you know you might be rendering a react component if he’s simulating user behavior but you know we’re not actually starting a browser or we’re not making really she’d appear requests we’re now getting a database anything like that and then there’s unit tests which we are for test testing kind of a single function in our case we’re talking about react components I think you can like some react if I mean if you’re not using doing any sort of user interaction simulating any events or anything like that you could make the argument that like you know testing that something renders is maybe a little bit more like a unit test I don’t care to really have that argument but I think you know this is this is much more kind of smaller single single units of code that don’t have many kind of other other modules that they depend on are interacting with the finally static and that I

think of this as like the static analysis that I mentioned earlier so think about typescript flow es lint those type of things that provide you immediate feedback while you’re writing the code alright so I mentioned you know I think I sorry I’ve mentioned this a couple times now but we’re gonna be focusing on react tests ret component tests and I just for I think of these as integration tests I think of most of what we’re gonna do here using react testing library as integration tests but just kind of fair warning Google go around you’ll he’ll hear some people call them unit tests and and other things too so getting into you know what is a the most basic JavaScript test we can even think about here this is really all the core of a test is we have an expectation that a value is going to is going to be something we’re gonna run some some code in that since some things should be like whether this value should equal something and we should get an error if that’s not the case so thinking about with just vanilla JavaScript what’s the most basic thing we can do this is about as close as you can get um but you’ll notice you know this this really isn’t very helpful in figuring out what is the actual issue here I mean we have some information you know that true is not false we have a stack trace here but there’s a lot it’s kind of hard to parse this and understand you know what’s really the issue here and this is where one of the first tools that we’ll look at here is going to provide a lot of values so that the focus here is going to be on react testing library but there’s this kind of framework called jest which is actually a few tools there just is a test runner an assertion library and also some utilities for mocking so it’s it’s kind of hard I want to differentiate those because they’re they actually are if you look at other tool chains like I mentioned MOCA earlier that’s a test runner and then we use chai to make assertions and then we use sign-on to do mocking so just as kind of all those things in one but a test Runner is helpful in this case because it can give us a kind of dsl like a domain-specific language for writing tests and then giving us more helpful output to actually identify where the issues are in our code so looking at Jess you know this is the exact same test but you can see a couple of things here so this test keyword this is part of the the jest Runner the the runner is gonna look at a bunch of files grab all the places where it sees this test keyword and it’s going to execute everything inside of here in once we get inside of this did the kind of callback that we either liked the function that we passed to the test this is actually this just assertion library so it’s it gives us these methods to say expect this thing to be this other value and just has all kinds of kind of more helpful methods like when we get to testing Dom objects there’s there’s things like to have attributes to have class you know all kinds you can extend this language to whatever you want it to be but I just want to call out that you know this is the kind of test runner and portion of this and this is the assertion library at work here and then looking at the output of a Jess test this is at least in my opinion a little bit more helpful output so look at you know points to the exact assertion that failed gives us the visual of the test it makes it very clear what the expected and received values were and just gives us some nice formatting you know if you have a whole suite here you’d see a bunch of green alongside the red here and that’s where you know you can you can start to think about – you know this is a description of the test I mentioned that these often serve as documentation if you think about you know describing the functionality of a module you can maybe see how the you know this formatting in here and how those descriptions of the tests start to read like documentation so that’s kind of the the tools and some background on like what the different levels of testing why I think it’s important what a test even is I’m going to jump into some coding like live coding just writing some tests but does anyone have any questions on the new ground we’ve covered so far

all right cool so like I mentioned before I’ll I’ll share these out later too so you can jump into these and play around with these if you want to I have in these examples kind of the starter here that where I’m going to try to like fill in the blanks writing the tests but I also have this like this finished test txx these so if you want to see kind of the you know what the final output or whatever if anyone comes to these later and also maybe in case if I you know get stuck I can reference that perhaps leading question helpful people who are doing the testing I’m just in the way that you might think about what you need to do in order to test to get a piece of functionality is it good practice to have one test sort of like a human would you know they’d have to create account than they after logging and they’d have to click this and put that to verify some behavior so you can think that it is like one action building upon another action building on another action until you get to an expected result is a good practice to have tests that need lhasa for each other or is it better to have each test coming field or run independently or do you ever not just one thousand of time view of the whole suite maybe a little bit you are your best practice in that regard might be helpful as we dig into the first couple right yeah for sure yeah all these examples are very trivialized from what you might see in a production app you know the feedback loop and these tests is gonna be almost instantaneous definitely not the case at work for me today you know there’s I would say thinking about like you definitely want to minimize the dependencies on your tests you want to be able to run them and ultimately you wanna you want a tight feedback loop like I said and the more dependencies you have to set up a test and get into the place where you can actually test the logic you care about the more expensive that is the slow your tests are gonna be and the longer that feedback loop is but again you know thinking about like an end to end test you know there’s there’s no way you can it’s gonna take some time you know to insert records in the post quiz and start a rails server and all that stuff to so there is there is no way around some of that but sorry I feel like I’m rambling you’re not answering your question oh yes yeah absolutely and it most of the testing tools that we have like we don’t even execute our tests in the same order because we want to watch out for the possibility that someone wrote a test and they almost like didn’t tear down the data correctly and there’s some like leftover state and there that actually makes the next test pass and you get a false positive so yeah you definitely like John said John John told me to write tests and now I write tests no thanks for calling that out I’d love to like get into maybe some conversation more about some of those general tests and best practices to it later on but yeah so thinking about how can we can everyone see the the font the code and everything okay decent size okay you might how can we test a react component the first thing we need to do is we just need to render it so thinking about you know how we render a react component and any we’re using react down the first thing we’re going to need is a an element just uh an HTML element we’ll create a div and then we’re gonna say reactant render I have this app component sir I’ll explain what that is in a second here and this is this is will verify that this is doing what it I think it is here but this is actually going to you know we now have a react app rendered inside of a kind of a virtual down so just uses something called j/s Dom which is like a simulated browser environment has all the API so you can call a document and then it has the method create element and you can you know create divs and think about things that look like

can be you know behave like all the normal Dom or like create gives you all those down the api’s but sorry before I get into this I wanted to [ __ ] I want to show what we’re actually testing this is an example from the react documentation they talking about one of the principles they have this kind of demo application it’s just a little to-do app so yeah you create my slides for this presentation and there’s no like checking things off or anything like that it’s just showing you know how you can kind of set state within the app and render render things the ultimately it’s just a form to create an item and then this list rendering the items and managing some state here for the app so well what we want to test right away in this test all I care about is that let’s get the component rendering and let’s just make sure that we can make some level assertions about on this so since we have all the Dom API is at our disposal we can do use things like query selector here and I know that there is an h1 on the page and we can say so we’re verifying that there’s an h1 on the page with text content of to do so I’m trying to verify that this is actually being rendered in this code sandbox thing it has an integration with jest that’s what we’re looking at here so I have it enabled that every time I update a file it’s gonna automatically run the tests and we’ll get a kind of a feedback loop here on the right side if I update this assertion so that it fails we can see you know like that example I showed before about with the the jest output um this example failure and then let’s also expect that we’re gonna have label for the input and it’s gonna be what needs to be done thank you and you can see it’s it’s highlighting it’s a little janky but it’s trying to highlight where the test failed so just another example of like tightening the feedback loop on your tests just I just want to call this out cuz it’s like a so there’s a lot of stuff I’m not going to talk about today that actually can be really nice for developer productivity and like this like automated test running and then like feedback in the in the editor like I don’t even need to let me think about I’m writing without this this panel open in my in my editor I’m getting feedback just like with es lint or like a typescript they’re like hey you’re not fulfilling the requirements for this test in real time and then the final thing here is I’m going to look for a button and that should have and number 1 all right and all of our tests are passing so all we did here was render the component make sure that there’s an h1 a label in this button here and then moving on to another example here like this this I mean this works this is like better than what we had before we are doing a lot like we are rendering thing rendering or react app in the Dom and making assertions but this is all still kind of kind of clunky you know actually using with the browser api’s it’s kind of inconvenient it’s also really easy to get a false positive I could write a really bad test here you know I just changed I did a typo here in this four attribute and if you look in the browser you know normally when I click the title it would it would it would highlight or it would focus the the textbox and a lot of screen readers rely on this type of functionality to be able to for people to navigate pages because the input doesn’t mean much to someone with the screen reader they can see that it has an ID and maybe they can infer a little bit from that but they have no idea what to put in this textbox what if I break this so I’m gonna leave that broken and this is where I want to reach for the first

tool from kind of the testing library toolkit so the testing library is kind of the namespace that a whole bunch of tools live underneath the first thing that they wrote was with the react testing library but from that they realized that there’s a whole bunch of things here that are not specific to react like you know we need at some level we need to just traverse the Dom and be able to get different elements in a nice way verify that like you know labels and inputs are connected correctly things like that and they’ve encapsulated all of those into something called the Dom testing library and we’re gonna work our way up towards the react testing library but I think it’s important to show rather than jumping there we’ll kind of see what all the what each individual tool does and work our way up to the bigger abstraction so this has something called get queries for element and here you know we’re using this you know we can pass in any sort of selector like a CSS selector to this query selector but like I mentioned that allows us to do a lot of kind of hacky things when you think about how a user uses they don’t go looking for an h1 they don’t go looking for a label they don’t go looking for a button element they look for the text you know what needs to be done look for the text you know to do is to understand like I’m on my to-do list so they’re these tools also really try to encourage thinking about testing from the users perspective you know I mentioned some tools like enzyme that we were using before and it kind of made it really easy to assert things like you know this prop is this value on a react component or the state inside this component is a certain thing but that’s actually you could kind of think of that as a code smell to test internals of the component like that when really all you’re like we should I think it’s helped more helpful to think about it as just just from the users perspective you know I see this input and I’m gonna and think about just in terms of like simulating their events and ultimately all that matters is what is rendered in the Dom so that’s all we we have access to so we are going to use this get queries for element on our root and then rather than doing you know querying the element and then using text content we are going to create the text and we’re going to use a method called get by text and get by label text so this is now and let’s just comment these out and make sure we still have a passing test okay so get by text works the that that is so present on the page that’s so we care about this well I’ll get to that in a second sorry again we’re gonna do get by in this case we’re going to use this method call get by label text and now this is just another example of react testing library kind of encouraging us to you know not only is this just finding though the label but it’s validating the contract that that label in the input have together so you can actually see oh yes sorry thank you we actually see we get a much more helpful error message here now so we found a label with the text but there’s no form control associated with it so now that has uncovered this issue that went unnoticed with you know our kind of naive just like using the Dom API s so that fixes that issue and then just get by text again all right and now our tests are passing again day we have a little cleaner API it reads a little bit nicer to rather than you know writ query

it cool I don’t even remember what the method was today’s query selector or whatever you know get by text get by label text they’re very relatively descriptive and it’s pretty clear what they’re doing but you can see there’s a lot of repetition here with like expect not to be null and really these are all going to throw an error if they fail anyway so I often just oops don’t even put the assertion around him you had a typo here as an example just to show this is gonna fail for you so you don’t actually need to put an expectation around them and it I mean there’s there’s different styles for reading these but on our team we’ve decided not because really all word I mean this is the finder but also the assertion for us so decent refactoring from where we were to to here and working our way up a little further we are but let’s take a look at react testing library for the first time here so you can see there’s a bunch of setup code here just to even get to the point where we can make assertions and you can see this is this is something we’re gonna need to do for almost every test so we’d probably think about you know do abstracting this let’s put this up here and then let’s pass in our component so our tests are passing again and this is a little bit nicer it’s much easier to focus on the real like meat of this test and it’s still relatively easy to see kind of what all the different pieces are doing here but this is where a react testing library comes in and all it really is is this for the main thing that people use it for is you know that it gives us this render method for us already and some facilities for that there’s a lot more that it does but the thing that you use for literally every test is is you know this render method which returns that get queries by element which will give you all these helpers kind of in the context so that react application you just rendered so again just going from this to refactoring with react testing library we also don’t need this and they just react Dom anymore either any questions so far and anything that we’ve gone through frequency oh yeah we you every piece of code that someone wants to push out into production we create like a change request saying hey I want to merge this code into production and it has to a few things have to happen in order for that for them to be able to do that so another engineer has to review the code and you use the tool called github and it’ll show a dip of like hey they deleted this line they added this line and it gives you a nice UI for commenting on the code and asking for changes and improving or denying but then also the github has all these checks that you can tie into so we actually run our entire test suite so it takes I think we have like 40 computers that we spin up for each test run that we let parallelize it over and it takes like 20 minutes so I mean it takes hours and hours to go through this whole test suite and we do that on every time anyone pushes any code that they want to get into production so we lean on it we run it I mean all the time every day like when I’m working in locally I never run the whole thing just because it takes so long but I always am running like the individual file that I’m looking at or the individual tests and I’ll set up either like this we have it automatically running the relevant tests or I have like in my editor just some key bindings and stuff to say like run this test quick to get because I think really yeah dinner data I keep talking about that feedback

loop I would and I think the tighter you can get that the more valuable they are yeah of course all right well let’s get into something a little bit more fun simulating user interaction so rendering the content we’re pretty good there it’s we’ve got you know our reactive rendering abstracted away with testing that Dom testing library another abstraction on top of that react testing library and now let’s tap into another tool from react testing library where we can simulate user user interactions so we’re gonna use something called fire event for that the first thing we’re gonna do is render our app again and then in order to simulate like a change or typing into an input the first thing we need to do is to well we need the the element that we’re gonna interact with so we can use one of these queries let’s say we’re gonna do Kip sorry get by label text and sorry like the syntax highlighting is off here I know so what needs to be done so this is gonna give us our input and then we’re gonna use fire event there’s a change method we passed the input that the element that we want to simulate the event on and then some information about the event and this syntax is a little bit wonky here but you I mean you there I’ll mention another tool to kind of make this a little bit I’ll will provide a little bit better and of helper for this – I think it’s target and then the value and let’s say we want what did we say we needed to do the react testing library presentation slides and then we want to fire another event to click the button and then we want to assert that the the react testing library presentation slides is present on the page and let’s also assert that the there’s some logic in the and this to change ad number one to ad number two so let’s assert that that’s there as well that updates correctly cool so tests are passing and we’re just with like relatively little code you know we’re assuming we have we’re simulating user events or and we’re testing we’re testing react components that actually handle user interaction you know so the way that it’s amazing I mentioned you know like enzyme before I mean really one of the big motivations we moved away from that was you know we might get something like the yeah this this would just return like a wrapper element and you just do you’d always be working with this this object called the wrapper and you would often just you can access the state of it like wrapper at state and you might test that a you know the to-do items are equal like you can make an expectation on this now that it’s like an array of the of the things that we just added and this just encouraged a bunch of bad testing habits that we just got rid of a whole class of issues the ones we once we kind of moved away from from that tool to react testing library it just doesn’t even give you the option to take access internals of your components like that what we found really refreshing I did mention we can there actually is a little easier way to simulate events here oops and using I’m using this code sandbox and again they have a nice UI

for like adding an additional dependency I added this user event library here another thing from react testing library or from a testing library folks yeah I’m probably gonna get this wrong I thought I could I don’t know if I have types for it but I think you can do I really shouldn’t try to do this on the fly because I’m forgetting the syntax but just know that this user event testing library exists and it makes some of the interactions stuff a little less painful I think I I link to it in one of the slides with some additional resources at the end gotcha yeah I didn’t know if using typescript if I had to install some types for it before I would get yeah so in this case I think the big thing is simulating input so like click isn’t as helpful but when you think about typing like sending a change event to an input element is it’s just like all the text at once versus in this case you can simulate like each keystroke with this API right here so if you if you really want to it’s a little bit nicer syntax but also a little bit more realistic user input as well so I’ll just leave it at a how to mention there and the final one I want to talk about here is testing async code so it’s often the case that you know to do anything meaningful in a test you know you’re you’re interacting with the server or there’s some something happening outside of the component that you need to interact with and just gives us some facilities for mocking like I mentioned so we’ve seen the test runner we’ve seen the assertion library and this is an example of of using the mocking API so normally you can you can actually do just just that mock and you can pass it a module this is kind of a unique like powerful thing about chess this will like mock everything on that namespace or everything in that module that you import because of code sandbox is the integration with jest for some reason that doesn’t work but so this is kind of a workaround but it provides the exact same API inside of our tests so I’m importing from this API module which is now being used there’s there’s one change in the application code here rather than just doing set items you know I’m actually making an API call to create this item I’m posting it to this to this endpoint and here’s the the new object that I’m that I’m sending there and then we get back the persisted item and then we put that into state in the react component so normally you you know we never want to hit an actual server in our tests or anything like that we also just don’t even have like a HTTP request environment like we would get an error if we actually tried to make a real HTTP request out of this so we’re gonna do is we’re gonna mock that entire module and like I said normally this would already be a mock but in this case I have to I’m using this like Jess dot FN which gives us like a mock function that we can make assertions on so mock create item the first thing we to do is say what we want this mock to return when it gets hit see mock resolved fail you once and we want to return something that looks like one of these to-do items and I can see we are you got to see the weird okay I can see where we’re gonna use this a lot so I’m just gonna oops pull this out to a variable so this is as this this code is also also needs to execute asynchronously now so by default you know it’s not going to know that it needs to to wait for this asynchronous code to run it’s just gonna try to render the app it’s gonna click Add and then we’re

looking for the test and it’s gonna further this text and it’s gonna fail because that is running this asynchronous action before and that is to finish and resolve before this text is going to update so we now need to make this code async so we can use a weight and with react testing library there’s all sorts of these kind of get by help helpers there’s equivalents for all these that will take a promise that start with fine and you can await those and another way to kind of to write this code is there’s actually a weight method that we can import from react testing library and I will get us back to to passing so now we sit with a with a couple lines of code here you know we mocked out the HTTP requests and we simulated where we were able to get this test passing so this is also kind of a kind of a side note like a benefit of abstracting away some of you are like if you have an API library putting it out into its own module so that you can do things like like in your tests here you can mock out the entire module really easily you could also think about setting up some kind of default resolved values with likes fixture data or something to make some of the setup code a little bit easier but then they I finally thought the one thing anytime you mock something you want to avoid kind of any sort of false positive and I think it’s nice to kind of make an assertion that the the mock was actually hit so I will say to have been called one time and then we can also let’s see to have been hold with so we can assert that it was hit with the correct value and that not always relevant but important to call out that you know some a lot of times you you won’t care necessarily about what’s happening with this data but you know that it’s going to kind of send some data outside of the component and you want to assert that it sent it in the right format so we know that we’re hitting the I think it was the items path and this is kind of a a little jest helper that they give you rather than defining the whole object with the ID because the ID is just the the current time and we could like mock out date dot now and control that ourselves but rather than do that I’m just gonna say I only care about one attribute on this so and I want to make sure it’s called with to do text and that’s passing again so with about we’ve covered about 90% of the API that I use in writing like most of my night tests and like our our app these are definitely simplified versions but hopefully understanding some of those kind of funk the building blocks of react testing library helps helps you kind of feel well understand what’s going on under the hood and hopefully help kind of it’s been helpful to me to understand things that way when I need to like debug things and really understand what something’s going wrong and yeah I’ve got a couple things here I’ll share out but I know where we’re getting laid here I bet my computer’s gonna die so a couple more resources here I’ve mentioned that I’ve got the code sandboxes here is that the event simulation that I mentioned we didn’t talk about hooks at all but react testing library has a specific react to extending library for for testing hooks too if you’re thinking about running accessibility tests this is something we were starting to use it will analyze a component and say like hey you’re missing the aria-label attribute on something where it’s supposed to be and you can specify like I want to be compliant with these different standards and it’ll they’ll do all that for you yeah that’s that’s all I got didn’t you open any questions or additional conversation but thank you so much for for your time and yeah sorry I got so late