 Okay, so I am P.P. Bhatwani. I work at Coug Tomorrow. It's an Australian health care start-up and we are basically into building health care apps for people and impacting their life in positive ways. And we have been talking about react-native, clutter, native script. So I'm gonna, I'm here to talk about testing in react-native. So do you want to learn it? Are you excited? Yes? No? Okay, so how many of you write tests? Raise your hands. And why do you think that testing is important? Anyone? Like, what? Client? Okay, okay, so I also have my views on it. But before I tell you that, I'm gonna tell you like a story. Okay? So when I started working with react-native project, I started small. So I started writing the UI components in the projects. And there was a component like blank card, which will like, if you pass anything to it, it will render into a very nice card view inside a very nice card view. So what I had to do is I wanted to write a test for it so that no one should mess up with the style of the card view. So the easiest way which I could start to write the UI test in react-native was snapshot testing. So snapshot testing basically like, when you like, when you run your, if you write a snapshot test, I'll show you in a while. But when you have a snapshot test and when you run it, if the snapshots are not there, they'll get generated. And if they are already there, then it will compare with the old snapshots. If they are the same, then the test will pass. If something has changed, then the test will fail. And then you can, you have to see and like what has changed. And if it was a required change or not. So for, I wanted, I wrote a test for the card view. So blank card, sorry. So you have to import the renderer and then you basically pass the render, the blank card to the renderer and create a snapshot. And when you do yarn test, it will generate something like this, which you can like understand. You have to look at it and see like what exactly is happening. I passed a text to it and it's just rendering inside the card view. And it gets saved. So tomorrow, if anyone will make any changes to my blank card, it will, it will fail. And I'll, I'll, I'll see that if it's, if the change is fine, like it's, it's the style, we have to change the style. I can just run a yarn test minus you update my snapshots. Otherwise I'll tell the person that please don't mess up with my styles. Okay. So there is that was about snapshot testing. Then this is like one of the nice command I came across, like if you want, suppose you're working. So and the one that any time you make any change, your test should run for that particular code. So you can just do yarn test minus, minus watch, and then it will run in an interactive mode where if whenever you will change, make any change in the code, the test related to that code will run. And you, it gives you an option of running all the codes, like all the tests at the same time, even like you can update the snapshots by like just pressing a to run all the tests minus you to update the snapshot. So it was really useful for us. And like when like writings, we saw that writing snapshot was really easy. So what I did, like I started writing some tests for all the components. But over time, I realized few things and I want to share with you like my learnings about snapshot testing. So what I realized is it's important to have short, short tests about like for the smaller components rather than having like if your component is too big, and if you're writing a snapshot test for it, it will generate a really big file, which will, which will be really difficult to go through and understand. So it's if you have a small component, then writing a snapshot test will be really good thing. And also, you need to have a good review culture. Like I told you that you can update snapshots like just like adding minus you and it will get updated. But suppose you your tests are failing, and no one is reviewing in the PR that what has changed in the snapshot, and they're just doing that yarn test minus you, they'll just test will pass. And then even if it was not intentional, it will get more. So it's really important that you decide a good code review culture in your company that whenever there are snapshots, have a look into them and see that it was like whether we want to update the test or not. And describe the test with meaning like this is really so important, because your test ultimately become documentation for people like who are going to just look into your code. So if you have written what exactly this test is going to do properly, like just describe it properly, then other people are going to understand like why what like why it is there, like what is the use of it. So moving on. After writing UI, I go like I went ahead and I started writing bigger screens and more logic. So there was this one screen we had my strategy. It's from an app which was basically tell you task if if based on your sleep, like if you're not sleeping properly, it will show you the task list, what you have to do to improve your sleep. And then if you the if this avatar you see, it's a nurse which like just shows the random messages based on your progress. Like if you have completed all tasks with a well done, and if you haven't completed, it will motivate you to do that. So my job was to write a method which will generate that random message based on different conditions. So we encourage and we follow TDD in our company. So what we tried to do is we try to write test first with the expected output. And then we write the logic. So I did the same like I started writing a test. I wrote a test that which is going to fail because there's no logic there. So I wrote that what it is what it should do. Then what is the expected behavior what I'm gonna get from the method get nurse message. And I was doing the session. So after that my next like I want had to decide that whether where should I write this get nurse message. I could either write it in my strategy screen and call it there itself. But my strategy screen was already very big. And I realize that if I'll put it there when I'm testing my strategy, I might have to mock that method. It's better to take it out and you know run it in isolation. So what I did I took it out in a class and then I wrote the method. So because I had tested my application and this has happened many times whenever I want to write a unit test. I could you know break down the bigger problem into smaller smaller things because I had to write methods which are testable small methods because if I start writing a big method, it will become difficult for me also to write the test for it. So writing unit test helps there a lot and also better architecture. So I'll tell you that whenever I wanted to write a test, I have if I'm not able to do anything, I try to figure out that what will be the good architecture. Like sometimes in Android, you have to follow a MVP pattern to be able to write unit test properly. So because you want to write test, you will go in that direction that you'll try to find ways of how you can code better. So this is this was like my experience. And that's makes you productive developer like if you're writing this. So the test which I wrote finally was like this. So all I had to do is after writing the method, I had to I had to pass the proper props to it. And that that was done. And while writing unit test, many times like I faced problems, like, like, how do you mock things? So there are like, if you go around, there are like mocking libraries and if you learn about how to mock functions in just so it is it is really easy like here, I've had to mock a random number generator method. What I did is I use the chest or mock method and I did I passed a method name, which I wanted to mock. So if you like if you feel that writing unit test is difficult, like it's it's not that difficult, you just have to find the right resources and then you can do pretty much everything in that after like, okay, so after learning about unit test, I wrote a few tests, all of us and then it was time to release the app. And but you know, like, if you want to release that we have to test the end to end close right properly and being into healthcare. It was really difficult for us to, you know, because in healthy, how to collect data, like you have forms, you have to collect data first and then based on that data, you have you show the task or whatever you want to do. So just imagine like writing like manually testing all different scenarios, we're like, and every time something is changing, again, you have to, you know, test everything. So what we want what we decided we'll write an e2e test for those things like the scenarios which are really important. And there was like detox, we went with detox it's an end to end testing framework for react, you can write your test for react native. And we wrote mostly the e2e test for iOS. It's also available on Android side. When we had tried, we were not able to run it properly on Android, but I think recently they have added more support to it. So and after that, like we decided what are the critical flows in our app with our product manager, and then we wrote e2e test for this because writing e2e test is like time consuming. When they run, it's really time consuming. So it's it was really important to decide in the talks, basically, you can write test using mocha, just and cucumber. And we wanted to write using to come up because we were already using it for different projects. And also, like when I'll show you the test, you'll also understand that how like why it is helpful. So if you go to the documentation of detox, there is already they have mentioned the like how you can, you know, take care of the test with mocha and just and we couldn't find like some how to set up with cucumber. So we asked it and you can go to this link and find out how you can do the setup. And then yeah, go like we went through the documentation did all the setup, you can follow the link here. The directory structure was like this, like we had an e2e folder. And there was a feature folder inside that we had a feature file. Basically, that's the test file. And there are some common steps to run the test. And hooks was to just set up the detox. So like if you go through the detox getting started guide, you'll get all this, like how you can set it up. And finally, let's try it, see some tests, some e2e test, you know, so I'm going to take an example of very like onboarding, because so that we can understand it better. So we had this onboarding component. And when you want to access anything from a component, you first have to give the test ID to it. Okay, so you give a test ID so that you can access it when you're writing the test. After that, we you write, we wrote a feature file. Okay, so we decide, like you write that, what is the feature about on boarding feature? And then this test ID basically is used to when you want to run the test. So you give this to detox that please run this test for me. So this is that one. And then you write the scenario. So this is in cucumber. So that's what the test if you write it in just a mocha, it will be different. So you write the scenario that I should be able to click the next bus button. And in cucumber, like going through cucumber is like out of scope of this talk, but I'll try to cover few basic things which are here. So given given and when then there are few keywords in cucumber, which helps you write the test and has some meaning like given, when you want to set an initial context, you say that I'm shown an onboarding screen. And if you want to continue that you add and keyword and then continue with that and I can see the agreement model screen. Then you want to perform some action you say that when I press the next button on onboarding screen. And then what should happen is you write it and then that then I should be shown the welcome screen. So this is like this was the like the test and like these statements, we had to like you have to write it. And like you have to write that that was like just for like, if you can read it and understand it, even if you sit with a product manager, they can sit and understand that but inside like you have to write the method of how it will work. So that given thing which I showed that I'm shown the screen. So here you basically passed the ID which we gave like the onboarding is the ID of the screen. So I'm shown the onboarding screen. It will go and try to these find the onboarding screen like and we are using the wait for add index and to these are like methods by detox so you can use these like I'm waiting for this element to come at index zero and like for some time we are waiting after that we are expecting that it's exist on the screen. So like this you have to write the description for all the steps, whatever are there and it's really easy like you can write this and make it like a method which you can reuse at multiple places. So this is just simple example of that. And after that, like after you wrote the test, how you can run it is you first have to add a configuration in your package.json basically defining that I want an iOS similar simulator device and I'm doing the debug configuration and you will specify which phone you gonna you want to run this test. So first you have to build a test in the talks using the talks bill command and you say that this is the configuration I want to build it. And after that, because like if you're not using cucumber, this the running step will be different. But we were using so cucumber. So we had to say that where the cucumber is where we are doing, where is our test and the onboarding minus t is the like which is the test we want to run at onboarding. I told you like remember that we gonna use it while running running the detox test and which is the configuration you want to run. And finally, it will look like this. It's basically how we do that it should go to the next step and then I should be shown a welcome screen. So all that steps will happen and test will pass like if anything is failing, then we come to know that there is a problem. So writing this test was like if suppose we didn't have this test, then every time the change is coming, we have to do it. But because we took time to write this once. Any time anything changes, what we did is we made a test suits of test which are really important. And then every time we have a release, we run that test suit on circles here for like maybe three hours. And then we know that they are all that like if those tests are passing that we make sure that we are these features are not affected by the change we have done. So my like, now I'll tell you the reason like why like testing is important for me is I feel that it helps us to write like documentation like you can write if you write your test properly and if you define describe them properly then anyone who is coming, we can you can ask them that just have a look into the test. If you don't understand then we can discuss more about it and I'm pretty sure that they'll understand that what's going to happen from that and you can refactor you refactor with confidence because you know that if test are passing you're changing anything and test are passing that means you're not affected the areas and at least to better design and and better user experience also because if the test are there then you have the sorority and your app which you got your and user going to use is going to be crash free and bug free less bugs at least. So that's it. Thank you for listening to me and I hope this really motivates you to write this and make you you make testing your friend like I have. So if you have any these are few useful resources I forgot to add one there is like a site called I'll share it later but that site has like different problems in different language and it all already like when you select a problem they all like have the test in it already described for you. So it helps you build going you know moving towards TTD. So you can then write the logic and run the test and if you want you can add more test as well. So if you want to improve that you can you know ask me I'll tell you the site and you can do that and if you want to reach you if you want to have any any questions you can miss email me or I'm very active on Twitter you can ask me on Twitter and let me know if you want to know anything I'll be happy to help. Thanks pretty any question.