 Welcome everyone to Glitter by Flutter by Shubhash Kottra. We are glad that Shubhash Kottra can join us today. Over to you Shubhash. Hello and a warm welcome to everyone. We are now attending the Glitter with Flutter session. As Shell has mentioned, I am Shubhash Kottra. And I am part of the SDET team from the company called Tite Platform and Technology Service Private Limited, which is basically a UK based scale up. And we are progressing well in India with respect to both technology and the business part. So today, we will briefly look after some of the key points of what a Flutter app is and the various ways of automating the Flutter app. And then probably I will take few questions if there are any. So let's start with something about Flutter, as some of us might know. Flutter is a cross platform software development framework, which is primarily being developed by Google and using the Dart programming language. By this, it means that the same code base can be used on Android, iOS, web, using the web views and even the desktop applications, right? Since we are using the same code base across for all of the features, functionalities and everything that we are developing, needless to say it helps in the faster production releases, right? Because even the testing efforts would be lesser than what it would take for any other app as such. I guess if there are any production product or release managers on this session, they would be really happy to hear this that we have something faster production releases. One of the state management patterns that is used in the Flutter framework and it is primarily used very heavily by all of the Flutter developers is termed as block, abbreviated as business logic component. It's basically an event and state management based sort of an architecture wherein an event is triggered and the state is accordingly caught with respect to the event and an action is performed accordingly. So as the name goes, it kind of separates out the business logic and the user interface. And because it separates out the business logic and the user interface, all of the rendering that happens on the screen is based on when and where it is basically needed and it helps in the testability and obviously the scalability with respect to the Flutter app. Because if for say tomorrow I as a Flutter developer want to add a new widget or a new field or an icon on the screen, it will be added there kind of in just as addition as a scalable part and then you can move in and it will be rendered and loaded on the screen only when it is needed and not right at the start. Obviously there could be a question that because the widgets are being loaded when it is needed, would there be an performance sampling with that? No. The architecture is written in such a way that the performance aspects of those parts are all taken care. Most of the Flutter developers basically use the Flutter framework that is available and has been developed by the community as such. The Flutter framework provides a very modern and the reactive framework with a rich set of platform layout and the foundation regions. So we have heard about widgets couple of times like what is a widget, there could be some people who might know what is a widget, some people who might be thinking what is a widget, right? So in Flutter terminology in Dart programming language terminology, anything that is to do with a screen, any field, it could be a button, it could be a text box, it could be the screen, it could be the layout. Anything and everything on a screen is termed as a widget and like we discussed because with the help of the block architecture and the reactive framework that Flutter framework uses. Every field or widget that we will be using going forward for this session, every field renders on its own whenever there is a need of rendering that. So now that we have looked at these parts. For sure, as it goes with any of the frameworks, we would definitely be meeting of managing any of the third party dependencies. Like for example, if I go back to the old school because I'm a old guy. In the old school part of Maven, for say we were using a form.xml to manage the third party dependencies. Then when we move to Gradle, it's basically the build.gradle. For iOS, we use Cocoa Pons. Similarly, for Flutter framework, we use pubspec.yaml. It's just like any other yml file and pubspec.yaml is what is there for Flutter for managing all of the third party dependencies. You add the corresponding dependency, the corresponding release of the dependency and the dependency will just be added just like build.gradle or any of the other parts that we just discussed. So now, as we have learned something and an introduction about the Flutter, let's take a look about the various ways of automating Flutter app. As we have with respect to automation, we would primarily or at a high level divide the automation test into two parts. Without looking at the testing pyramid, first say I'll come back to why I'm not looking at the testing pyramid later on. On a high level for automation tests, we have two parts, the unit test and the end-to-end automation test. In the Flutter part, with respect to unit tests, there are three types of unit tests. One, the obvious traditional unit test, needless to say the traditional unit test the classes individually in isolation and it gives us the specific feedback with respect to that particular class. And the subsequent bug or anything that could have been missed with respect to the specific class wouldn't be going further than where it is now. And that's the benefit of unit test. We all know that. In addition to the unit test, the traditional unit test, in Flutter, we also have widget tests. As we learned earlier in field on a screen is termed as widget. In Flutter, there is a possibility of writing tests to test these particular widgets. Say for example, we would want to test an action on a particular widget, an action on a particular button, an action, try to enter something on a text box. We would want to see whether the screen is properly rendered or not, the screen is properly laid out or not. So for those, all of these things, we have widget tests. And as part of the testing community for so long with all of you, I guess we would, to some extent, at least agree that with our traditional end-to-end automation test, there is a possibility sometimes that we might miss some of the fields which are present on the screen because sometimes end-to-end automation tests might not be requiring to act or to perform an action on each and every field on that particular screen. There is a possibility, I'm not saying that it is always, but there is definitely a possibility that we might miss a particular field during our end-to-end automation test because it was not required or for any other specific reasons as such. But with these widget tests that are provided for the Flutter framework, we could potentially write tests for each of these widgets and make sure that each of the widgets on that particular screen is indeed working. And hence, the bugs that might have occurred if that particular widget was not tested would be seen much earlier in the release cycle and obviously the cost associated with the bug would be coming down drastically. With respect to widget tests in the Flutter, the framework that was developed by the community has given a superpower for the widget test by including a package called as golden underscore toolkit. This golden underscore toolkit package helps us in writing golden tests as such. What these golden tests are? It's nothing but probably for say someone who's testing on iOS or someone who writes unique tests for iOS. It's primarily the same as a snapshot test. It just compares an image, a baseline image, which I would take at the start of the project and compares it with the latest release that's coming up. So for example, I have this image that's there in the upcoming commit for the next release for say this Test Flutter app goes somewhere here. So this screen is now matched with the baseline image that I already have and tells us that, okay, the Test Flutter app was present here but it is now shown here. So with this, it gives us the feedback and we as testers can go back and see whether this particular changes indeed needed for that commit, needed for that particular release or not, and then log bugs or do accordingly whatever we would want to. So it is a good way of checking whether there are any distortions or screen layout issues with respect to the screens as such using the golden test. However, there is a glitch because it's an image and it's an image comparison. So it is extremely fragile in terms of where and how we are testing primarily based on the host platform and the host OS. So for example, if I'm running golden test called as a on my Mac, it gives a result as our per se. I'm running the same golden test a on a Windows machine. The result are might look the same way as it was on a Mac machine might not look the same way because a Mac, the way a Mac renders an image and the way windows renders an image has a lot of differences. And that's where we as a testing team might not be completely sure whether it's an issue with respect to the code or it's an issue with respect to the OS. In addition, because it's all images and the image comparisons, there is a requirement from the Flutter framework as as to whenever there is a new Flutter major release that's coming up, we would have to regenerate all of the baseline images that I have created at the start. So it's an overhead in terms of I have already created some baseline images again have to create again have to maintain maintainability is is is a big challenge in terms of, you know, where do you keep all of these baseline images where do you keep the upcoming current images, all those parts right because images are heavy. You don't want to keep them on your local or some AWS AWS space will go off and things like that. So, because of all of these, I would leave it to the corresponding testing team. For me, I would probably not suggest entirely to use golden test completely. But I would leave it to the testing corresponding testing team in your community to see if you would actually want it in your testing strategy or no. So with that, since we have looked at some of the unit tests and how we are testing those unit tests with respect to the Flutter apps. Let's move on to the point of interest for us for this session which is into an automation test. So, as a testing community on the selenium conference on that app in part, anything that we are testing a mobile app. The first thing that comes to our mind is obviously the medium right we as selenium test is a p m test is the first thing that we would go to is a p m Flutter drive a p m to test whether the Flutter app is being tested is being able to test using a p m module. And definitely thanks to the APM community, they have indeed given the APM Flutter driver, which supports the automation of Flutter apps using the driver. There isn't any major change as such. You just have to use the same basic concepts of APM you can configure the APM driver. You pretty much add all of the required capabilities that are needed for for your specific tests and you just go on with your tests. That's how simple and effective APM is and definitely a big big close to the complete APM community to incorporate something as new as Flutter within the very early stages of Flutter being represented in the market and APM community has already added that, which is a very good, very good thing from the APM community. Having said that, while we were doing all of these VOCs for our Flutter apps because we at time are looking very strongly at Flutter and we are very proud of using Flutter as a development tool. So the apps are being built on on Flutter. So we as the automation testers or we as the SDS, we would want to automate these apps and and look for a effective thing that helps us in all of the possible ways. So while doing these for VOCs, when we try to do APM or use the APM Flutter driver, we observed that there are certain challenges, especially related to the element identification and specially on the web views because on the one Flutter app, there will be native Flutter apps and native Flutter screens and as well as the Flutter web views. So these element identification issues were primarily either part of we having to write long X paths or long locators to actually locate an element or sometimes even not able to identify a particular element on a web view. And to mitigate this sort of a challenge at that particular moment when we started looking at the VOCs and stuff. We thought of looking at why not we we could look some for some other alternative apart from APM. Yes, we are all comfortable with APM. We are all happy with APM. But because of these challenges, let's also take an alternative approach or at least look if there is any ultimate approach to test or to do end to end automation tests. For a Flutter app. And that's what that's how we figured out that there is indeed a package called as integration underscore test. And this package is obviously present in the Flutter framework. The advantage of this is it is tightly coupled with the devs code and we would have to use the same code base the same repo which is present on the Flutter Flutter actual Flutter devs code. And since it's the same code base and the same repo, we will use the same programming language that's not but for developing our automation tests as well. And since it's the same again, the same package of integration test is present on the Flutter. It would support anything right from an app screen, when I say app screen, it's a mobile screen or a web view or a desktop app screen right so using the same part. It's the same repo you could potentially test all of them with within the same part and you don't have to go back to say APM or encoded UI or something of that sort to actually test desktop applications and sort of that right. So that's one of the advantages that we saw in the initial space. And then we started looking at a bit detailed view. Till now in the past quarter or more than quarter that we have looked into integration test as a package, we haven't seen any element identification issues as such. And even if we come across, because it's in the same repo, you could always go to the particular widget that you are looking and look for the properties that are present for that widget, use the property in automation test in the same repo. Directly call that widget, directly call that widget present in a particular class and do your stuff right. In addition, obviously, because it's the same repo, you could potentially want to change or add any property that you would want for your automation test to be performing better. It's not suggestible because it's a depth script, you don't want to directly modify any widget's property without having a discussion with the particular depth team or something but there is a possibility. That the repo is present. You suggest to the depth team, these are the property changes that I would need. I can go ahead and change it with a PR, you approve it and it would help my end of automation test. So these are some of the benefits that we have seen. And it is built on a Flutter driver, which is again part of the Flutter framework, which helps us in writing the Flutter test as an end-to-end test, much more easier because the Flutter driver is present within this code.