Look into the Future of React Native Testing Library
Subtitles
Show
welcome everybody to the first episode of react native podcast that we are hosting at coldstack today with me uh is the first special guest mike p who works with me at call stack so just break the ice mike if you could tell us a bit more about yourself and what are you doing at call stack so hey um i'm mikhail i worked i work as a software developer and a team leader here at pro stack on that daily basis i develop react native apps for for our clients and nfu open source libraries uh like reacting to the same library snapshot dev just uh being native cli and probably a bunch of others i guess that's it cool cool thanks for thanks for thanks for doing that am i right that uh that you're wearing a uh either jest or a hacktoberfest t-shirt right now does it stop the purpose yeah there you go there you go there you go so you're also very very uh into open source and uh um uh the reason i'm bringing up just t-shirt is that we are also doing a lot of contributions to that library in fact i think ever since i met you uh uh that was one of one of the one of the reasons why why we met and i and i if i remember correctly um you were actually wearing just t-shirt the first time we met so that's how i i uh how it all started so uh interesting inside anyway um now that we are talking about just i think one one one thing that is very very special and uh special about you is that you are very very into testing and every time we talk about testing here at call stack you seem to speak up and bring a lot of great insights uh so tell me a bit more about that how how
where is the passion to testing coming from because i think that it's not that popular topic amongst us uh we we prefer to write and just release and ship it and forget but you are always the one who's reminding us that we should test it all so how where it all started what's the story behind that yeah so it started by accident actually um so i started to follow a bunch of people on twitter and and somebody um encouraged like new contributions to a few open source libraries and it turned out that one of them is is just and it was like almost just uh rewritten to be to be usable by christopher mcasaway and uh and somehow it turned out that i started to contribute to this library and and get and and that's what i got interested into into testing right because i was kind of ashamed that prior to those first contributions uh i didn't test my software and i heard that you should write tests like unit integration tests back-end developers do it all the time and when it comes to frontline development it's kind of sticky slippery topic right so uh not not too many people knew at the time how to efficiently test software um javascript some interactions then react so so that's how i got like gradually interested in into the topic and uh yeah that's that's basically it yeah i think that i'm a lot of these developers that you're talking about because uh ever since i remember i always had problems differentiating end-to-end tests from you know black box tests
integration tests and all these kind of things i guess uh the only piece of testing that i really mastered when i was just starting was unit tests because that was the easiest thing to do but rather than that uh you know i think that working with you i actually learned a lot about these things so uh that was awesome uh cool so i i uh uh getting getting a bit more to the topic of today podcast which is a react native testing library uh it is a utility for for testing react native apps that you've been working on um so um i think you are the best person to tell everybody listening to us what is this library doing and and what is the case use case for it uh so if you could just uh if we could just start with a very very brief introduction to how it all started and and why i should choose that library uh um from amongst all the others that exist in the ecosystem yeah so maybe let's start what the big native texan library is so yeah the if you're familiar with with react testing library or dom testing library or older testing libraries started by by kent c dots then regnated testing library is like re-implementation of uh the same apis in the reactive realm so the difference is that we our library is not dependent on dom apis because we don't run reagnative and dom we run in javascript environments with some special functions uh but it's it's pretty far away from from dom right so so we render into a custom node.
js environment and and to do that we as as an implementation detail of the library we don't use the
js environment and and to do that we as as an implementation detail of the library we don't use the
javascript dom implementations but rather use react test render to do the stuff for us and and because we realize that using react test renderer as like the experiences is not so great like you have to wrap everything in act you you have to um manipulate their instances you can access some some basically implementation details of the components so um it was uh it was like doing one of the projects when we were writing test for for one of our clients we realized that it's really cumbersome to to use this and we also didn't want to use enzyme because it kind of encouraged you to uh to write tests that uh that are certain implementation details for example change the state of the component and and at the time there was really close to uh like riyadh was really close to release react hooks and it turned out that all of those tests all of those tests written in ensem uh would have to be rewritten for example so we turned uh we we came up with uh with our own uh set of helpers and and reactors in library came out at the um a few few months later if i correct if i remember correctly still we got inspired by their apis and kind of re-implemented this so that's the story behind the library we try to be as compatible uh with the with the rest of the ecosystem rest of the libraries as possible uh but historically we started from from a different place and kind of uh we're just getting into this compatibility uh so we had some apis that were as we mark them today unsafe um uh or we allowed for for shallow rendering for example uh
so so it took us time to to gradually uh migrate off of those apis and today we can say that we're almost compatible with uh like as as much as we can basically so so the goal is if if you render if you test your react apps with react as a library uh you should be able to seamlessly go to react native and use a different library but with with the same habits same same helpers and and same ecosystem okay so if i'm getting this right the idea with uh with the library is to focus on on not testing the internals and not depending on what's inside but rather using those uh those those apis uh that we refer to as queries for for doing things yes but that's that's basically it our one of the main goals of the library is to make it very hard to assert on the implementation details of the real components that you test so we want to be as close to the user interactions and user experience as possible so the queries are they allow you to to find elements on your screen by text or by some accessibility helpers or input values but you're not allowed to manually change the state of your component or or grab some uh i don't find find a specific proper of a component and or find it by by a name and kind of get away with that with your writing test so we we want our tests to resemble um how the user is actually using the app so uh so that's that's the main goal and uh and the rest is like the whole api is is a reflection of this of this idea okay cool so i understand uh so so that makes a lot of sense and i
guess just to just to just to just to clear it up um uh because you mentioned the the two alternatives uh that are available were the enzyme and react test vendor um so so i guess i guess um the difference from the first one was uh the the shallow versus deep rendering um did i did i got this right uh so not exactly so uh okay and enzyme is it's a really good libraries right so it's pretty versatile and you can uh you can write your unit tests uh by shallow rendering stuff you can write you can render deeply into the um into the dom structure don't hierarchy uh so you can do a lot and the problem is that you probably can do too much right so so that was the problem with enzyme and it turned out that the the developers and the community uh around ensem uh started to exploit some uh unsafe testing patterns that in in the future uh they they made it harder for you to for example refactor your code structurally yeah when you were migrating from uh react classes to to hooks to functions for example um so so so that's about it i i don't uh i won't say that uh enzyme is a bad library it's uh it just allows for too much and our idea is to uh not allow the for developers to do anything but just enough to to be productive yeah writing tests and i and i think and i think this was um this is also something that you share uh with the distinct library itself i i think when can't open source this whole concept because i i think testing library is more of a concept it was more like a paradigm for testing in general
um we have specific implementations right um do you do you know like what were the the core principles of that pattern of that approach i think the the one that you said which is not rely on the internals i was that was the was that was the one thing is there anything else that can't and the whole testing library community truly believes uh believes in yeah yeah so uh the testing library uh it's an organization uh on github for example now so there's a whole community around it and they believe that your tests should resemble the way your user uses your app and and that's that's it and this determines uh the um like inability to test implementation details and uh and the api that's more resembling end-to-end testing uh frameworks where you can click uh send a new event uh find something by text this is this is not a regular uh unit testing it's it's like uh the api and evolved in in a way that you're writing your queries as you would be a user uh to that want to achieve some specific uh goal or uh or go through a specific flow of the application but you're still rendered in in the emulated javascript environment so so you don't have to pay the cost of running emulator or a browser or anything like this yeah that makes a lot of sense and i think this is why it is just much easier and faster to set it up compared to alternatives such as uh detox i guess which is also the library that you had a lot of experience with if i if i recom i won't say i have two i have a lot of experience with detox uh i've just just just enough to to be
productive right uh and so dx is completely different library uh it's uh it's end-to-end testing or or ui testing or functional uh however you like to call it uh the thing is that it's we shouldn't write too much of or or too many of the uh end-to-end tests um because of their qualities right they they serve as really nice indication that our app actually works from end to end um involving our front-end back-end databases uh transport layers and all of that so so that's that's the great thing about end-to-end testing and detox allow us to to do so uh but it's also um a uh um a shortcoming right so um yeah because you have so many systems involved a lot more can go wrong basically right yeah we've been we've been we've been running detox uh on the react native repo and you know every time i've been working on the release i understand that they can go wrong from time to time so if you are looking for something 100 stable this might not be the best option uh which is not the detox fold itself it's just how the things work these days um cool yeah so it's actually pretty yeah that's actually pretty nice that reg native is using a community library like detox to yeah to test their uh their up and to end uh yeah i heard it's really really fun stuff to do to restore the defect services yeah well this is it is not something that i usually do i just report stuff so i'm on this easier side of things just testing but but yeah you're right and um the good thing though about this is that every time we upgrade react native to a
newer version we can make sure that detox works which historically been a problem um because there were some breaking changes and you know it's been it's been it's been tough from time to time but the detox team has been doing great job so um kudos on that for them uh cool mike so how about you kind of maybe give us a quick run through some examples that you have in the docs and maybe maybe show us how these uh things work in practice um i gotta i got a brief understanding of you know uh what's going on about this react native testing library but because i'm more of a cto slash manager kind of guy these days um this kind of uh run through the docks will be a uh good for me and for those of our uh listeners uh that haven't used this library before so how about how about doing a quick uh demo of the library yeah so so this is our our website uh it's it's rendered i mean it's it's hosted on the github pages we build it with docusaurus library uh from our main repository and um i must say it's really a pleasure to work with docuseries there is almost no hacking we need to do to uh to be happy about and it supports dark mode so there you go that's a nice that uh so yeah um these are like the the goals of the library that we uh we want our tests to be maintainable reliable and uh and and the up the library is community driven yeah i'd love i'd love i'd love my tests to be community driven though yeah so uh call stack is is like one of the leading companies in the big native ecosystem and we are we are proud that we can uh support so
many libraries and react native testing library is is one of them so i want to make sure that people see that the developers uh realized that uh the same people that work on other reactive libraries um also work on their um testing libraries so so i think i think that's uh um that's nice and here we have some introduction if you're new to the library and this is a some contribute example we i can go through it so we can import like render and fire event helpers from the regulator's testing library we import our test components we write the tests we set up some data some mocks and and this is a crucial part we render our component uh yeah yeah it's uh we pass it some props that you wanna test on uh our mocks if you wanna test on subnet and once it's rendered it returns an object with a bunch of helpers and we call them queries so those queries are like this one get by accessibility label now so we can find a specific accessibility label and view a chiraqi or we can find something by text and once we have those query selected we can we can call them with specific inputs so so here we for example want to find answer input by accessibility label because we we know uh it's it's a thing and if there is a person with uh if there's a user with a voice over or or similar technology uh using our app uh we can be sure that our like this part of our app is accessible uh and we embrace that in in tests so it's also
it's sometimes hard to figure out how to grab something interactable or uh or an image or so and then it turns out that our non visual users also have those problems so so by focusing on on restricting this api we try to make developers think about their accessibility uh in in their apps so now we have grabbed our inputs and uh and we can fire some events like we can change the text inside the input because the the input can have the unchanged text prop that that it respects when when the user input is is inserted and so so we we can use fire event um to emulate that uh it's we can emulate any event uh but there um there are three um grievance that we uh make it that are like pre nah uh um predefined yeah so so so like we uh uh how to like to nicely say it yeah uh they're like baked in into uh yeah yeah so so the so those events are uh the ones that users are using uh are most likely using which is change text which is pressing and scrolling uh so so yeah so we can uh uh as you can see we we find an instance that was found uh by the um by the query uh and we can we can make another query to get this instance like in this case we uh we look for submit text into um inside our view hierarchy and press it as the user would yeah and then we um we check if um if if our on submit was called with specific uh uh specific uh data right so so just one just one question uh actually i got a lot of them but i need to make sure we fit in time uh so i can see that there is two kinds
of uh functions that we work with some of them are coming from the rear native testing library name space and they seem to be like global functions and we also have some uh some like an object with those queries returned from render function and these are scoped let's say to the component itself right yes exactly okay cool um that makes that makes a lot of sense so my next question was like what are all the queries uh that i should be aware of uh apart from get by text and ghetto by accessibility label i'm not sure if that's what you were i'm pretty sure that that's what you were going to talk about anyway but i just wanted to uh bring that up so uh we have we have a handful of methods here and render is the most important of them we just got to know it when we go through that basic example um we have cleanup that's that's being called automatically so you don't ever have to think about it it unmounts your components so so so your data from your components does not leak to another test uh we have fire event we also know that already there's a bunch of predefined fire events like compress change text scroll we have wait four which is handful if we want to wait for some non-deterministic periods of time until an element appears or times out and so this can be um element appearing in our view hierarchy or basically anything else this is so if i have something so if i have something async going on uh this is this is what i should probably use to just wait for for it to happen yeah but there are better
ways to do it so wait for is uh also this is api that you probably not need to uh to use too often at least there is wait for element to be removed which is the opposite of the wait for and it's it's helpful to uh to test if some something disappeared from uh from the screen for example uh after some animation is done or so um we have a weapon this is pretty uh interesting one uh once you once you render some once you render your component and have the queries available it may happen that the component is so big that you want to scope the um those queries to some smaller chunk of that component so within this is basically this it will it takes an instance that you that you just took and that you that you just um found for example with uh um with another query and and you can search inside uh cool this new instance so and and it only um only return a query so the uh some some other methods returned by render are not available here makes makes sense and then we have the query and choreo apis this is stuff returned from render and we have act which is which is a helper from the reactus renderer and it's re-exported almost directly we support uh a synchronous and asynchronous uh version of act and uh and yeah we can go back to the render and the interesting thing is this queries right so um we know that we can um we can return some queries that will allow us to get grub stuff by text or by accessibility and i will get to the list of them soon and the render also returns a few other helpers
scoped to this very component that we are rendering for example update or alias re-render which will re-render our component if you want to test mounting and unmounting for example we can amount a a a component uh oh yeah that that was that was wrong re-rentable just re-renter it won't unlock yeah sorry about that uh so for mount mount we have another options we we have a debug that will return a a shallow or uh or deep um character pretty printed in our console and we have to json which uh which will return the the json karaki um of our uh of our review that we that we just rendered and this may be helpful for uh for some snapshot testing yeah that's that's exactly what i thought when you said json i was like snapshot testing is going to be the way to go yeah yeah so we can jump to queries and uh queries have a few variants right so those variants are get query and fine and the the difference is that they they all uh allow you to do the same they they allow you to use those queries which work which graph the react test instances by text or by placeholder test id accessibility label and such but but they behave a bit differently in terms of uh throwing of what what's happening when a specific instance is found or not so get by and get all by will will uh so get by will uh return a query and we'll return a test uh instance of uh um of what we want to find and if it doesn't uh if it doesn't find any anything that that's matching the query it will throw an error that's important
stuff and and similar is for the get all by it will return an array of matching nodes for a query and throw an error if there's no element match so query is just like guess y but it won't throw it will return low and it's also uh convenient to use sometimes if you want to see if an element uh is doesn't exist in the character and we don't wanna play with uh catching the air and such query all by the same but with uh with multiple multiple items if there's no items found it will return an empty array and fund buy is a convenience wrapper around the the get buy uh plus it's uh it's running wait for underneath so it's an asynchronous query that that we we believe you should be using most of the time uh because it's very convenient uh there's a lot of asynchronous stuff [Music] happening when rendering our views and our components so instead of using weight for directly we can use a weight find by some query and it will it will wait for an element to appear for example or a bunch of elements to appear in our hierarchy so we don't ever have to think about a christian chronity in our apps it's it's very nice upgrade from using get buy and query buy and plus wait for and uh um and and the good thing that the library is doing for you uh as i as i mentioned about this act is is that whenever we render uh or update or wait for an element uh [Music] we we wrap those updates in act for you so uh so there's only a bunch of
scenarios where you actually need to use act directly most of the time you don't ever have to think about it okay and what does this act function itself is doing it are we supposed to do yeah so act is a helper from from the react test renderer that makes your test behave makes react behave uh more similar uh to the browser environment in your testing environment so okay what they mean by that is uh react can uh for example patch multiple state updates in in in a in know one update for example so uh they they can do it uh in probably in uh in concurrent mode uh they can add it uh sooner or later and and when they dispatch because they have a synthetic event implementation uh they can do a bunch of uh um crazy and less crazy optimization to optimizations to to how the events are passed in the browser so they can pass them directly or batch them in multiple groups so the act is a way to preserve this behavior inside node environment so whenever you're trying to uh to update state of your component uh and don't use act to uh and don't wrap the state update in inside the act helper reactance render will yell at you that you didn't wrap your state update just do it right so yeah so our library uh does it for you now so you almost never have to think about it but there are times where uh where those warnings will still happen uh but it's it's it's not the shortcoming of the library it's uh yeah it's react core team uh preventing you from from doing uh some silly errors
that you may have not thought about it yeah all right mike uh so thanks for doing that deep dive into the api that was very insightful um there is one question that i wanted to ask you and i know that you love this question uh and the question is uh how is react native testing library uh different from a uh something that i've i've heard uh native testing library which is actually listed on the the on the testing library website um what's the story behind that why is that why is that why is that why that change and and can we expect anything uh to happen around that yeah so uh every time we release a new version of the library we get asked the same questions why are we uh why did we ended up having two libraries doing uh exactly the same nah see the the thing number one is that they are not the same uh they have the same apis uh or very similar at least uh they work differently under the hood and and our library was the first one to to come up as an open source library and there's this native texan library which is renamed as an official testing library slash react native um was created a bit later and it was actually created like behind our backs we we didn't like this situation we had uh um we had some uh offline conversations uh with with kent and uh and the creator of the library and that this is not an optimal situation for for our community but in the end we um we didn't come up with uh with the agreement on uh what to do in the situation so so we kept the status quo uh by having
two libraries so uh so the one the official one is uh it's not our library but our library is uh um is as as we already uh as we say it on uh on the documentation this is community driven and uh specifically regulative community driven and uh developed by uh call stack which invests a lot in into making this this library usable and uh easy to maintain and the main ability is the biggest difference between those libraries so our idea is to uh is to have a thinnest possible abstraction layer or talk on top over the react test renderer and not introducing any hacks specific to to react native uh so so so some reignitive uh apis that or actually very native mocks that are let's say not not ideally re-implemented in inside javascript from their negative components um we don't do anything to to fix them right we uh we believe that they should be fixed upstream while the other library uh tries to fix stuff that big native marks that's the biggest difference and it allows us to move really fast to be compatible with any version of react native while the second library has currently issues with with the maintenance maintenance um and and that's because the the way the uh [Music] they wanted to deal with uh with problems that were in our opinion uh not a responsibility of a tested library but reunited itself so that's how it looks today and uh but there is there is uh there is
actually a uh some some bright future uh ahead ahead of us because uh with the like one of the um one other difference between our libraries is that we in our version one allowed for shallow rendering or uh or introduce some unsafe uh unsafe queries that were not aligned with the guiding principles of of the same library i guess that was one of those problems between like testing library one and yeah yeah and the the thing is that we couldn't uh migrate off of those uh apis too fast and just break everybody because there were already a lot of users including our clients uh that were using this library so we we couldn't afford uh to break everything so so that we're now officially um compatible with the guiding principles of tesla nice so so we've came up with uh with a long plan on how to address the all of those issues and and that's how we came up with v2 which got released a few weeks ago and and v2 is it's fairly easy to uh to upgrade from the v1 uh we've prepared a thorough migration guide blog post uh with rationality uh behind our decisions and with this version we are practically compatible with with the with other intestine libraries with their apis we made sure that that that we native testing library is is compatible with uh also some community libraries around eslint or or custom just matchers so so we did a lot of work uh to uh that was incremental and uh and allow everybody to to upgrade seamlessly um or at least we we hope so that it's a seamless upgrade
we didn't have we didn't see uh too many issues um when upgrading our internal apps uh or or our clients apps and and and also it's it's been a few weeks already uh since the release of v2 and we didn't have any have any uh like issues created around the pain for upgrading so uh so we read this as a small success that we uh we managed to remove or at least rename some of the um dangerous apis and allow for gradual upgrades to to our users and this was um [Music] uh it seems like this was a also assigned to to kent uh the creator of this libraries uh that maybe it's time to uh to do something about those uh uh the split inside the community uh that we have two to libraries for destiny native and we are actually uh like right now we uh we we have uh like almost clear path to to resolve this situation and in the nearest future our library will will hopefully become the library to test react native and the second one will be phased out and the missing parts is is that we need to come up with uh with a good migration strategy but shouldn't be problematic because the apis are the same but we wanna gonna make it as easy for the community as uh as possible and this is actually very very exciting and that after all this time um after having two libraries doing the same uh we end up like joining them and have the best of both worlds yeah yeah it's i guess it's it's good to see some positive uh feedback out coming out of you know healthy competition happening inside the community
with two libraries trying to kind of become the uh the factor standard for for testing so it's good good to see that i'm really excited about that because i know that you've been spending a lot of your time and then the regime to kind of doing that and because you're passionate about testing your like fully immersed uh beta library so uh you mentioned already um you mentioned already that the v2 is is the library where is the version where you you're finally compatible with the guiding principles and that's one thing um so i just wanted to ask if there is anything that you wanted to highlight as far as v2 if there is anybody listening to us that have been using v1 um i guess that might be it might be worth to just quickly glance for the most important changes uh and if there is anything that you wanted to highlight please do i'm really curious about what's inside uh yeah of course so uh we uh we introduced a bunch of um upgrades and cleanups uh inside uh v2 but they were like some of them were only uh maintenance wise which is uh for example dropping note 8 that reached the end of life with with the end of 2019 um and we also removed oh i'll just go one by one uh we've introduced a automatic cleanup uh which also works the same in the um in the react testing library it's even more important there because it also cleans up the dom state we don't use dom so we only unmount the component and we use the same the same apis to as the reactor sync library to to enable or disable this behavior so uh so that that's one of the compatibility changes
another one is uh wait for api changes uh our the signature of and the name of our uh wait for element uh function was a bit different uh so we've made it that it's it's exactly the same as the distant library so it's named to wait four yeah it has options object uh fairly trivial upgrade uh there's not too many users that tweak those options anyway so it's ninety percent of uh changes just renamed wait for element to wait for um also wait for another um like productivity and uh ease of use upgrade is that we now wrap uh wait for calls inside uh inside act so we don't have to think about it and and we also in the then the in the last version of uh of version one um we introduced the find the buy which which uh which was also missing from our api uh so we removed the global debug function this was something that we introduced uh in the very first version and then it turned out that it's easier to use debug directly from the rendered component because we we are usually interested in that uh so we removed removed the legacy helper we removed the shallow function which is a very simple implementation so if anybody wants to use shallow rendering uh and there are some uh justifications to use it if you're uh if you're happily invested into unit testing uh like very very unique testing of your rare components but the thing is that those components need to be super simple and if you if you add state to it you may have troubles with difference
between shallow and deep rendering so we generally discovered from using that that's why uh uh that's why we remove it removed it uh but yeah if you if you use shallow in your test you can implement it with with this few lines of code and migrate off of this api later we removed um some others yeah i mean just just we removed one actually one uh one query which is by name it was all right uh it was very it was a mistake from from the very beginning but we we actually use this api and some of our apps so we deprecated it like a year ago and we spawned warnings for that and now it's uh now it's completely removed uh so so if you if you relied on get by name uh i mean you already uh been warned uh and uh now it's just uh impossible to use it it's very it's very easy to replace it with get by type uh which also which was also really renamed to to be unsafe goodbye type and and the unsafe as we call them queries are getting by type and getting by props because they assert on on certain implementation details of your component that the components that you want to test integration of but it's not always a bad thing to do it that's why we leave those apis because we know there are users that that successfully test their components or some of the components using those queries so so we just renamed them and we don't have plans to to remove those for now they're shouting at you that it's unsafe and you basically need to know what you're doing because fun fact is that a lot of developers don't know what they're doing they're
testing they just want to bump their coverage up so so we want to make it as easy for them as as possible so to not be a an expert in testing uh just to test your rear components um we fixed a long-standing bug in uh in the get by test id query uh so this this may be uh problematic in some some cases uh the details are here you can uh you can read them if you if you hit those uh um edge cases and we've deprecated and planned to remove the flash micro task queue uh this very simple helper as a one-liner and it's usually not necessary to use it it's better to use find buy or wait for yeah yeah and that's um that's basically it apart from those um those applications we made sure we're compatible with few community libraries and and this makes us very easy to be super compatible with other testing libraries nice nice uh thanks for thanks for running through those uh changes i see that the general pattern here is that you're trying to be focusing on the highest level of testing if possible without letting or without encouraging people to go deeper and and focusing on like flashing micro task queue etc like these are the details that you should not worry about i see that uh like i like what you said at the beginning that the react native testing library focuses on testing the apps the way users interact with it and users don't care about your task queue or you know waiting for something yeah exactly the outcome cool
mikey thanks for thanks for joining and thanks for you know being the first um guest on our podcast yeah thank you as well it's been it's been pleasure and uh yeah i'm really really looking forward to all the changes that you will be releasing in the future again as i said i i wish you best of luck these these are like really great this is a really great work that you've done and you your team does so far and i'm keeping my fingers crossed for all the great work that you have in plants and again thanks for joining and you know best of luck with the developments in the react native testing library yeah thank you as well uh thanks for inviting me uh to this podcast i really look forward uh for the next episodes uh really interesting in what you have in store here uh for this podcast thank you thank you uh you know uh hold on hold on with being excited because i might call you for being a co-host so you know you never know i know i know i know you know i know you very well all right mikey uh thanks for thanks to that um i'll let you know when we are up in the air and meanwhile have a nice day and thanks again for your time here on the podcast yeah thank you take care thank you bye bye
Timestamps
Show
Guests
Michał Pierzchala
Principal Engineer
@
Callstack
welcome everybody to the first episode of react native podcast that we are hosting at coldstack today with me uh is the first special guest mike p who works with me at call stack so just break the ice mike if you could tell us a bit more about yourself and what are you doing at call stack so hey um i'm mikhail i worked i work as a software developer and a team leader here at pro stack on that daily basis i develop react native apps for for our clients and nfu open source libraries uh like reacting to the same library snapshot dev just uh being native cli and probably a bunch of others i guess that's it cool cool thanks for thanks for thanks for doing that am i right that uh that you're wearing a uh either jest or a hacktoberfest t-shirt right now does it stop the purpose yeah there you go there you go there you go so you're also very very uh into open source and uh um uh the reason i'm bringing up just t-shirt is that we are also doing a lot of contributions to that library in fact i think ever since i met you uh uh that was one of one of the one of the reasons why why we met and i and i if i remember correctly um you were actually wearing just t-shirt the first time we met so that's how i i uh how it all started so uh interesting inside anyway um now that we are talking about just i think one one one thing that is very very special and uh special about you is that you are very very into testing and every time we talk about testing here at call stack you seem to speak up and bring a lot of great insights uh so tell me a bit more about that how how
where is the passion to testing coming from because i think that it's not that popular topic amongst us uh we we prefer to write and just release and ship it and forget but you are always the one who's reminding us that we should test it all so how where it all started what's the story behind that yeah so it started by accident actually um so i started to follow a bunch of people on twitter and and somebody um encouraged like new contributions to a few open source libraries and it turned out that one of them is is just and it was like almost just uh rewritten to be to be usable by christopher mcasaway and uh and somehow it turned out that i started to contribute to this library and and get and and that's what i got interested into into testing right because i was kind of ashamed that prior to those first contributions uh i didn't test my software and i heard that you should write tests like unit integration tests back-end developers do it all the time and when it comes to frontline development it's kind of sticky slippery topic right so uh not not too many people knew at the time how to efficiently test software um javascript some interactions then react so so that's how i got like gradually interested in into the topic and uh yeah that's that's basically it yeah i think that i'm a lot of these developers that you're talking about because uh ever since i remember i always had problems differentiating end-to-end tests from you know black box tests
integration tests and all these kind of things i guess uh the only piece of testing that i really mastered when i was just starting was unit tests because that was the easiest thing to do but rather than that uh you know i think that working with you i actually learned a lot about these things so uh that was awesome uh cool so i i uh uh getting getting a bit more to the topic of today podcast which is a react native testing library uh it is a utility for for testing react native apps that you've been working on um so um i think you are the best person to tell everybody listening to us what is this library doing and and what is the case use case for it uh so if you could just uh if we could just start with a very very brief introduction to how it all started and and why i should choose that library uh um from amongst all the others that exist in the ecosystem yeah so maybe let's start what the big native texan library is so yeah the if you're familiar with with react testing library or dom testing library or older testing libraries started by by kent c dots then regnated testing library is like re-implementation of uh the same apis in the reactive realm so the difference is that we our library is not dependent on dom apis because we don't run reagnative and dom we run in javascript environments with some special functions uh but it's it's pretty far away from from dom right so so we render into a custom node.
js environment and and to do that we as as an implementation detail of the library we don't use the
js environment and and to do that we as as an implementation detail of the library we don't use the
javascript dom implementations but rather use react test render to do the stuff for us and and because we realize that using react test renderer as like the experiences is not so great like you have to wrap everything in act you you have to um manipulate their instances you can access some some basically implementation details of the components so um it was uh it was like doing one of the projects when we were writing test for for one of our clients we realized that it's really cumbersome to to use this and we also didn't want to use enzyme because it kind of encouraged you to uh to write tests that uh that are certain implementation details for example change the state of the component and and at the time there was really close to uh like riyadh was really close to release react hooks and it turned out that all of those tests all of those tests written in ensem uh would have to be rewritten for example so we turned uh we we came up with uh with our own uh set of helpers and and reactors in library came out at the um a few few months later if i correct if i remember correctly still we got inspired by their apis and kind of re-implemented this so that's the story behind the library we try to be as compatible uh with the with the rest of the ecosystem rest of the libraries as possible uh but historically we started from from a different place and kind of uh we're just getting into this compatibility uh so we had some apis that were as we mark them today unsafe um uh or we allowed for for shallow rendering for example uh
so so it took us time to to gradually uh migrate off of those apis and today we can say that we're almost compatible with uh like as as much as we can basically so so the goal is if if you render if you test your react apps with react as a library uh you should be able to seamlessly go to react native and use a different library but with with the same habits same same helpers and and same ecosystem okay so if i'm getting this right the idea with uh with the library is to focus on on not testing the internals and not depending on what's inside but rather using those uh those those apis uh that we refer to as queries for for doing things yes but that's that's basically it our one of the main goals of the library is to make it very hard to assert on the implementation details of the real components that you test so we want to be as close to the user interactions and user experience as possible so the queries are they allow you to to find elements on your screen by text or by some accessibility helpers or input values but you're not allowed to manually change the state of your component or or grab some uh i don't find find a specific proper of a component and or find it by by a name and kind of get away with that with your writing test so we we want our tests to resemble um how the user is actually using the app so uh so that's that's the main goal and uh and the rest is like the whole api is is a reflection of this of this idea okay cool so i understand uh so so that makes a lot of sense and i
guess just to just to just to just to clear it up um uh because you mentioned the the two alternatives uh that are available were the enzyme and react test vendor um so so i guess i guess um the difference from the first one was uh the the shallow versus deep rendering um did i did i got this right uh so not exactly so uh okay and enzyme is it's a really good libraries right so it's pretty versatile and you can uh you can write your unit tests uh by shallow rendering stuff you can write you can render deeply into the um into the dom structure don't hierarchy uh so you can do a lot and the problem is that you probably can do too much right so so that was the problem with enzyme and it turned out that the the developers and the community uh around ensem uh started to exploit some uh unsafe testing patterns that in in the future uh they they made it harder for you to for example refactor your code structurally yeah when you were migrating from uh react classes to to hooks to functions for example um so so so that's about it i i don't uh i won't say that uh enzyme is a bad library it's uh it just allows for too much and our idea is to uh not allow the for developers to do anything but just enough to to be productive yeah writing tests and i and i think and i think this was um this is also something that you share uh with the distinct library itself i i think when can't open source this whole concept because i i think testing library is more of a concept it was more like a paradigm for testing in general
um we have specific implementations right um do you do you know like what were the the core principles of that pattern of that approach i think the the one that you said which is not rely on the internals i was that was the was that was the one thing is there anything else that can't and the whole testing library community truly believes uh believes in yeah yeah so uh the testing library uh it's an organization uh on github for example now so there's a whole community around it and they believe that your tests should resemble the way your user uses your app and and that's that's it and this determines uh the um like inability to test implementation details and uh and the api that's more resembling end-to-end testing uh frameworks where you can click uh send a new event uh find something by text this is this is not a regular uh unit testing it's it's like uh the api and evolved in in a way that you're writing your queries as you would be a user uh to that want to achieve some specific uh goal or uh or go through a specific flow of the application but you're still rendered in in the emulated javascript environment so so you don't have to pay the cost of running emulator or a browser or anything like this yeah that makes a lot of sense and i think this is why it is just much easier and faster to set it up compared to alternatives such as uh detox i guess which is also the library that you had a lot of experience with if i if i recom i won't say i have two i have a lot of experience with detox uh i've just just just enough to to be
productive right uh and so dx is completely different library uh it's uh it's end-to-end testing or or ui testing or functional uh however you like to call it uh the thing is that it's we shouldn't write too much of or or too many of the uh end-to-end tests um because of their qualities right they they serve as really nice indication that our app actually works from end to end um involving our front-end back-end databases uh transport layers and all of that so so that's that's the great thing about end-to-end testing and detox allow us to to do so uh but it's also um a uh um a shortcoming right so um yeah because you have so many systems involved a lot more can go wrong basically right yeah we've been we've been we've been running detox uh on the react native repo and you know every time i've been working on the release i understand that they can go wrong from time to time so if you are looking for something 100 stable this might not be the best option uh which is not the detox fold itself it's just how the things work these days um cool yeah so it's actually pretty yeah that's actually pretty nice that reg native is using a community library like detox to yeah to test their uh their up and to end uh yeah i heard it's really really fun stuff to do to restore the defect services yeah well this is it is not something that i usually do i just report stuff so i'm on this easier side of things just testing but but yeah you're right and um the good thing though about this is that every time we upgrade react native to a
newer version we can make sure that detox works which historically been a problem um because there were some breaking changes and you know it's been it's been it's been tough from time to time but the detox team has been doing great job so um kudos on that for them uh cool mike so how about you kind of maybe give us a quick run through some examples that you have in the docs and maybe maybe show us how these uh things work in practice um i gotta i got a brief understanding of you know uh what's going on about this react native testing library but because i'm more of a cto slash manager kind of guy these days um this kind of uh run through the docks will be a uh good for me and for those of our uh listeners uh that haven't used this library before so how about how about doing a quick uh demo of the library yeah so so this is our our website uh it's it's rendered i mean it's it's hosted on the github pages we build it with docusaurus library uh from our main repository and um i must say it's really a pleasure to work with docuseries there is almost no hacking we need to do to uh to be happy about and it supports dark mode so there you go that's a nice that uh so yeah um these are like the the goals of the library that we uh we want our tests to be maintainable reliable and uh and and the up the library is community driven yeah i'd love i'd love i'd love my tests to be community driven though yeah so uh call stack is is like one of the leading companies in the big native ecosystem and we are we are proud that we can uh support so
many libraries and react native testing library is is one of them so i want to make sure that people see that the developers uh realized that uh the same people that work on other reactive libraries um also work on their um testing libraries so so i think i think that's uh um that's nice and here we have some introduction if you're new to the library and this is a some contribute example we i can go through it so we can import like render and fire event helpers from the regulator's testing library we import our test components we write the tests we set up some data some mocks and and this is a crucial part we render our component uh yeah yeah it's uh we pass it some props that you wanna test on uh our mocks if you wanna test on subnet and once it's rendered it returns an object with a bunch of helpers and we call them queries so those queries are like this one get by accessibility label now so we can find a specific accessibility label and view a chiraqi or we can find something by text and once we have those query selected we can we can call them with specific inputs so so here we for example want to find answer input by accessibility label because we we know uh it's it's a thing and if there is a person with uh if there's a user with a voice over or or similar technology uh using our app uh we can be sure that our like this part of our app is accessible uh and we embrace that in in tests so it's also
it's sometimes hard to figure out how to grab something interactable or uh or an image or so and then it turns out that our non visual users also have those problems so so by focusing on on restricting this api we try to make developers think about their accessibility uh in in their apps so now we have grabbed our inputs and uh and we can fire some events like we can change the text inside the input because the the input can have the unchanged text prop that that it respects when when the user input is is inserted and so so we we can use fire event um to emulate that uh it's we can emulate any event uh but there um there are three um grievance that we uh make it that are like pre nah uh um predefined yeah so so so like we uh uh how to like to nicely say it yeah uh they're like baked in into uh yeah yeah so so the so those events are uh the ones that users are using uh are most likely using which is change text which is pressing and scrolling uh so so yeah so we can uh uh as you can see we we find an instance that was found uh by the um by the query uh and we can we can make another query to get this instance like in this case we uh we look for submit text into um inside our view hierarchy and press it as the user would yeah and then we um we check if um if if our on submit was called with specific uh uh specific uh data right so so just one just one question uh actually i got a lot of them but i need to make sure we fit in time uh so i can see that there is two kinds
of uh functions that we work with some of them are coming from the rear native testing library name space and they seem to be like global functions and we also have some uh some like an object with those queries returned from render function and these are scoped let's say to the component itself right yes exactly okay cool um that makes that makes a lot of sense so my next question was like what are all the queries uh that i should be aware of uh apart from get by text and ghetto by accessibility label i'm not sure if that's what you were i'm pretty sure that that's what you were going to talk about anyway but i just wanted to uh bring that up so uh we have we have a handful of methods here and render is the most important of them we just got to know it when we go through that basic example um we have cleanup that's that's being called automatically so you don't ever have to think about it it unmounts your components so so so your data from your components does not leak to another test uh we have fire event we also know that already there's a bunch of predefined fire events like compress change text scroll we have wait four which is handful if we want to wait for some non-deterministic periods of time until an element appears or times out and so this can be um element appearing in our view hierarchy or basically anything else this is so if i have something so if i have something async going on uh this is this is what i should probably use to just wait for for it to happen yeah but there are better
ways to do it so wait for is uh also this is api that you probably not need to uh to use too often at least there is wait for element to be removed which is the opposite of the wait for and it's it's helpful to uh to test if some something disappeared from uh from the screen for example uh after some animation is done or so um we have a weapon this is pretty uh interesting one uh once you once you render some once you render your component and have the queries available it may happen that the component is so big that you want to scope the um those queries to some smaller chunk of that component so within this is basically this it will it takes an instance that you that you just took and that you that you just um found for example with uh um with another query and and you can search inside uh cool this new instance so and and it only um only return a query so the uh some some other methods returned by render are not available here makes makes sense and then we have the query and choreo apis this is stuff returned from render and we have act which is which is a helper from the reactus renderer and it's re-exported almost directly we support uh a synchronous and asynchronous uh version of act and uh and yeah we can go back to the render and the interesting thing is this queries right so um we know that we can um we can return some queries that will allow us to get grub stuff by text or by accessibility and i will get to the list of them soon and the render also returns a few other helpers
scoped to this very component that we are rendering for example update or alias re-render which will re-render our component if you want to test mounting and unmounting for example we can amount a a a component uh oh yeah that that was that was wrong re-rentable just re-renter it won't unlock yeah sorry about that uh so for mount mount we have another options we we have a debug that will return a a shallow or uh or deep um character pretty printed in our console and we have to json which uh which will return the the json karaki um of our uh of our review that we that we just rendered and this may be helpful for uh for some snapshot testing yeah that's that's exactly what i thought when you said json i was like snapshot testing is going to be the way to go yeah yeah so we can jump to queries and uh queries have a few variants right so those variants are get query and fine and the the difference is that they they all uh allow you to do the same they they allow you to use those queries which work which graph the react test instances by text or by placeholder test id accessibility label and such but but they behave a bit differently in terms of uh throwing of what what's happening when a specific instance is found or not so get by and get all by will will uh so get by will uh return a query and we'll return a test uh instance of uh um of what we want to find and if it doesn't uh if it doesn't find any anything that that's matching the query it will throw an error that's important
stuff and and similar is for the get all by it will return an array of matching nodes for a query and throw an error if there's no element match so query is just like guess y but it won't throw it will return low and it's also uh convenient to use sometimes if you want to see if an element uh is doesn't exist in the character and we don't wanna play with uh catching the air and such query all by the same but with uh with multiple multiple items if there's no items found it will return an empty array and fund buy is a convenience wrapper around the the get buy uh plus it's uh it's running wait for underneath so it's an asynchronous query that that we we believe you should be using most of the time uh because it's very convenient uh there's a lot of asynchronous stuff [Music] happening when rendering our views and our components so instead of using weight for directly we can use a weight find by some query and it will it will wait for an element to appear for example or a bunch of elements to appear in our hierarchy so we don't ever have to think about a christian chronity in our apps it's it's very nice upgrade from using get buy and query buy and plus wait for and uh um and and the good thing that the library is doing for you uh as i as i mentioned about this act is is that whenever we render uh or update or wait for an element uh [Music] we we wrap those updates in act for you so uh so there's only a bunch of
scenarios where you actually need to use act directly most of the time you don't ever have to think about it okay and what does this act function itself is doing it are we supposed to do yeah so act is a helper from from the react test renderer that makes your test behave makes react behave uh more similar uh to the browser environment in your testing environment so okay what they mean by that is uh react can uh for example patch multiple state updates in in in a in know one update for example so uh they they can do it uh in probably in uh in concurrent mode uh they can add it uh sooner or later and and when they dispatch because they have a synthetic event implementation uh they can do a bunch of uh um crazy and less crazy optimization to optimizations to to how the events are passed in the browser so they can pass them directly or batch them in multiple groups so the act is a way to preserve this behavior inside node environment so whenever you're trying to uh to update state of your component uh and don't use act to uh and don't wrap the state update in inside the act helper reactance render will yell at you that you didn't wrap your state update just do it right so yeah so our library uh does it for you now so you almost never have to think about it but there are times where uh where those warnings will still happen uh but it's it's it's not the shortcoming of the library it's uh yeah it's react core team uh preventing you from from doing uh some silly errors
that you may have not thought about it yeah all right mike uh so thanks for doing that deep dive into the api that was very insightful um there is one question that i wanted to ask you and i know that you love this question uh and the question is uh how is react native testing library uh different from a uh something that i've i've heard uh native testing library which is actually listed on the the on the testing library website um what's the story behind that why is that why is that why is that why that change and and can we expect anything uh to happen around that yeah so uh every time we release a new version of the library we get asked the same questions why are we uh why did we ended up having two libraries doing uh exactly the same nah see the the thing number one is that they are not the same uh they have the same apis uh or very similar at least uh they work differently under the hood and and our library was the first one to to come up as an open source library and there's this native texan library which is renamed as an official testing library slash react native um was created a bit later and it was actually created like behind our backs we we didn't like this situation we had uh um we had some uh offline conversations uh with with kent and uh and the creator of the library and that this is not an optimal situation for for our community but in the end we um we didn't come up with uh with the agreement on uh what to do in the situation so so we kept the status quo uh by having
two libraries so uh so the one the official one is uh it's not our library but our library is uh um is as as we already uh as we say it on uh on the documentation this is community driven and uh specifically regulative community driven and uh developed by uh call stack which invests a lot in into making this this library usable and uh easy to maintain and the main ability is the biggest difference between those libraries so our idea is to uh is to have a thinnest possible abstraction layer or talk on top over the react test renderer and not introducing any hacks specific to to react native uh so so so some reignitive uh apis that or actually very native mocks that are let's say not not ideally re-implemented in inside javascript from their negative components um we don't do anything to to fix them right we uh we believe that they should be fixed upstream while the other library uh tries to fix stuff that big native marks that's the biggest difference and it allows us to move really fast to be compatible with any version of react native while the second library has currently issues with with the maintenance maintenance um and and that's because the the way the uh [Music] they wanted to deal with uh with problems that were in our opinion uh not a responsibility of a tested library but reunited itself so that's how it looks today and uh but there is there is uh there is
actually a uh some some bright future uh ahead ahead of us because uh with the like one of the um one other difference between our libraries is that we in our version one allowed for shallow rendering or uh or introduce some unsafe uh unsafe queries that were not aligned with the guiding principles of of the same library i guess that was one of those problems between like testing library one and yeah yeah and the the thing is that we couldn't uh migrate off of those uh apis too fast and just break everybody because there were already a lot of users including our clients uh that were using this library so we we couldn't afford uh to break everything so so that we're now officially um compatible with the guiding principles of tesla nice so so we've came up with uh with a long plan on how to address the all of those issues and and that's how we came up with v2 which got released a few weeks ago and and v2 is it's fairly easy to uh to upgrade from the v1 uh we've prepared a thorough migration guide blog post uh with rationality uh behind our decisions and with this version we are practically compatible with with the with other intestine libraries with their apis we made sure that that that we native testing library is is compatible with uh also some community libraries around eslint or or custom just matchers so so we did a lot of work uh to uh that was incremental and uh and allow everybody to to upgrade seamlessly um or at least we we hope so that it's a seamless upgrade
we didn't have we didn't see uh too many issues um when upgrading our internal apps uh or or our clients apps and and and also it's it's been a few weeks already uh since the release of v2 and we didn't have any have any uh like issues created around the pain for upgrading so uh so we read this as a small success that we uh we managed to remove or at least rename some of the um dangerous apis and allow for gradual upgrades to to our users and this was um [Music] uh it seems like this was a also assigned to to kent uh the creator of this libraries uh that maybe it's time to uh to do something about those uh uh the split inside the community uh that we have two to libraries for destiny native and we are actually uh like right now we uh we we have uh like almost clear path to to resolve this situation and in the nearest future our library will will hopefully become the library to test react native and the second one will be phased out and the missing parts is is that we need to come up with uh with a good migration strategy but shouldn't be problematic because the apis are the same but we wanna gonna make it as easy for the community as uh as possible and this is actually very very exciting and that after all this time um after having two libraries doing the same uh we end up like joining them and have the best of both worlds yeah yeah it's i guess it's it's good to see some positive uh feedback out coming out of you know healthy competition happening inside the community
with two libraries trying to kind of become the uh the factor standard for for testing so it's good good to see that i'm really excited about that because i know that you've been spending a lot of your time and then the regime to kind of doing that and because you're passionate about testing your like fully immersed uh beta library so uh you mentioned already um you mentioned already that the v2 is is the library where is the version where you you're finally compatible with the guiding principles and that's one thing um so i just wanted to ask if there is anything that you wanted to highlight as far as v2 if there is anybody listening to us that have been using v1 um i guess that might be it might be worth to just quickly glance for the most important changes uh and if there is anything that you wanted to highlight please do i'm really curious about what's inside uh yeah of course so uh we uh we introduced a bunch of um upgrades and cleanups uh inside uh v2 but they were like some of them were only uh maintenance wise which is uh for example dropping note 8 that reached the end of life with with the end of 2019 um and we also removed oh i'll just go one by one uh we've introduced a automatic cleanup uh which also works the same in the um in the react testing library it's even more important there because it also cleans up the dom state we don't use dom so we only unmount the component and we use the same the same apis to as the reactor sync library to to enable or disable this behavior so uh so that that's one of the compatibility changes
another one is uh wait for api changes uh our the signature of and the name of our uh wait for element uh function was a bit different uh so we've made it that it's it's exactly the same as the distant library so it's named to wait four yeah it has options object uh fairly trivial upgrade uh there's not too many users that tweak those options anyway so it's ninety percent of uh changes just renamed wait for element to wait for um also wait for another um like productivity and uh ease of use upgrade is that we now wrap uh wait for calls inside uh inside act so we don't have to think about it and and we also in the then the in the last version of uh of version one um we introduced the find the buy which which uh which was also missing from our api uh so we removed the global debug function this was something that we introduced uh in the very first version and then it turned out that it's easier to use debug directly from the rendered component because we we are usually interested in that uh so we removed removed the legacy helper we removed the shallow function which is a very simple implementation so if anybody wants to use shallow rendering uh and there are some uh justifications to use it if you're uh if you're happily invested into unit testing uh like very very unique testing of your rare components but the thing is that those components need to be super simple and if you if you add state to it you may have troubles with difference
between shallow and deep rendering so we generally discovered from using that that's why uh uh that's why we remove it removed it uh but yeah if you if you use shallow in your test you can implement it with with this few lines of code and migrate off of this api later we removed um some others yeah i mean just just we removed one actually one uh one query which is by name it was all right uh it was very it was a mistake from from the very beginning but we we actually use this api and some of our apps so we deprecated it like a year ago and we spawned warnings for that and now it's uh now it's completely removed uh so so if you if you relied on get by name uh i mean you already uh been warned uh and uh now it's just uh impossible to use it it's very it's very easy to replace it with get by type uh which also which was also really renamed to to be unsafe goodbye type and and the unsafe as we call them queries are getting by type and getting by props because they assert on on certain implementation details of your component that the components that you want to test integration of but it's not always a bad thing to do it that's why we leave those apis because we know there are users that that successfully test their components or some of the components using those queries so so we just renamed them and we don't have plans to to remove those for now they're shouting at you that it's unsafe and you basically need to know what you're doing because fun fact is that a lot of developers don't know what they're doing they're
testing they just want to bump their coverage up so so we want to make it as easy for them as as possible so to not be a an expert in testing uh just to test your rear components um we fixed a long-standing bug in uh in the get by test id query uh so this this may be uh problematic in some some cases uh the details are here you can uh you can read them if you if you hit those uh um edge cases and we've deprecated and planned to remove the flash micro task queue uh this very simple helper as a one-liner and it's usually not necessary to use it it's better to use find buy or wait for yeah yeah and that's um that's basically it apart from those um those applications we made sure we're compatible with few community libraries and and this makes us very easy to be super compatible with other testing libraries nice nice uh thanks for thanks for running through those uh changes i see that the general pattern here is that you're trying to be focusing on the highest level of testing if possible without letting or without encouraging people to go deeper and and focusing on like flashing micro task queue etc like these are the details that you should not worry about i see that uh like i like what you said at the beginning that the react native testing library focuses on testing the apps the way users interact with it and users don't care about your task queue or you know waiting for something yeah exactly the outcome cool
mikey thanks for thanks for joining and thanks for you know being the first um guest on our podcast yeah thank you as well it's been it's been pleasure and uh yeah i'm really really looking forward to all the changes that you will be releasing in the future again as i said i i wish you best of luck these these are like really great this is a really great work that you've done and you your team does so far and i'm keeping my fingers crossed for all the great work that you have in plants and again thanks for joining and you know best of luck with the developments in the react native testing library yeah thank you as well uh thanks for inviting me uh to this podcast i really look forward uh for the next episodes uh really interesting in what you have in store here uh for this podcast thank you thank you uh you know uh hold on hold on with being excited because i might call you for being a co-host so you know you never know i know i know i know you know i know you very well all right mikey uh thanks for thanks to that um i'll let you know when we are up in the air and meanwhile have a nice day and thanks again for your time here on the podcast yeah thank you take care thank you bye bye
Show Transcript
The first episode of React Universe On Air (formerly known as The React Native Show) provides insights into React Native Testing Library. Mike and his guest give a quick glimpse into the very concept of "Testing Library" and tell the story behind "React Native Testing Library."
The React Native Testing Library Explained
If you are familiar with any Testing Library started by Kent C. Dodds, you will find it easy to use React Native Testing Library as it's based on the same APIs. React Native Testing Library does not depend on DOM APIs though - we run the tests in a Node.js environment utilizing the React Test Renderer, which renders React components in memory. Learn more about the Library from Michał.
Mike and his guest also address the following questions:
- What kind of technical differences are between RNTL and the ecosystem? And why so many?
- What is the current state of the library?
- What is the future of the React Native Testing Library?
Once you check the episode, find out what's new in React Native Testing Library 2.0 and how to migrate to the new version.
Strengthening your React Native testing setup?
We assist with setting up robust testing strategies for React Native apps.
Let’s chat
//
Insights
Learn more about
Testing
Here's everything we published recently on this topic.
//
Testing
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
Quality Assurance
Combine automated and manual testing with CI/CD integration to catch issues early and deliver reliable React Native releases.
Release Process Optimization
Ship faster with optimized CI/CD pipelines, automated deployments, and scalable release workflows for React Native apps.
React Compiler Implementation
Use React Compiler to achieve instant performance benefits in your existing applications.
React Native Trainings
Equip your team with React Native skills through tailored training sessions.
