-
Dear Community - Has anyone had the possibility to build their tests using the page object model structure with patrol? The idea is to have every mobile screen defined as a class for better structure together with their locators, methods etc. If anyone has an example it would be highly appreciated as I am currently in the research phase and pretty new to dart and flutter as a whole. Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
Hi @s0leris, thanks for asking - that's a great question. I'm not a tester myself, so can't really answer it, but I have a few colleagues who should be able to help you :) |
Beta Was this translation helpful? Give feedback.
-
Hi @s0leris, I raised the same question myself couple of months ago. From my personal experience with Patrol the best approach is not to have a Page class for every screen in the app due to reduced device size. Instead of that I write a separate Page for a group of screens that are closely related to each other. If one screen has button that displays full screen timePicker widget there is no point in creating separate class for it. If one Page starts to get too big I just split it. Reshaping POM takes a very little time - just write couple of tests the "plain" way and see for yourself which screens could be merged to avoid having one function Pages. It's difficult to provide an example since mobile apps differ from each other so much. The only drawback I encountered is that I wasn't able to store widget keys anywhere besides I've been working with Patrol for about 9 months now as a tester, let me know if you have any more questions :) |
Beta Was this translation helpful? Give feedback.
-
I am not yet so deep into Patrol test automation, but to me the page object model is one of many possible ways to increase maintainability and readability of the test code. And it might not fit good to mobile apps as written above, which I can imagine. Cypress has an interesting approach where they recommend not to use page objects but instead what they call "app actions". I am not sure if that technique can be applied to mobile apps too in some way. If you want to read about it, Cypress describes it on their pages. I found an easier understandable explanation about "app actions" in a blog. |
Beta Was this translation helpful? Give feedback.
-
Hi! That is really a good question. I kept myself thinking about a page object model to use in a Flutter project, for Integration Testing or Patrol approach. Well, I try to share my ideas here, but first I will give a small context: I am a software test analyst and I studied Flutter in my free time just enough to be able to create a project to use it as a ‘tool’ to train the test analysts in the company I work for, then I would have a project where I could raise questions and trainings as test case writing, test plan elaborations (regression, smoke...) best practices and of course automation using the project. My project simulates a bancary app where the user can log in and transfer money to other accounts, and some more things. Well, returning to the topic of this thread, I organized the artifacts following the structure of page object model. In the lib I have the presenters/transfer/transfer_receipt_view.dart, then in the integration_test I will have screens/transfer/transfer_receipt_screen.dart: (Please note that the .dart files from the project end with the suffix ‘_presenter’ and the .dart files of POM end with the suffix ‘_screen’) Then inside the file ‘transfer_receipt_screen.dart’ I put the methods related to the screen: I followed this idea to the other views. Other thing I had to create was a way to make more than one validation in a same test. In the time I was automating I looked but I did not find a way to make many validations in a same test run. Well, there is a way, but if the first validation fails, the test ends and do not validate the other ones, which in my opinion is not very effective depending of the test. I would like to share the idea, may be useful to someone to apply in the POM. Maybe there is a better way and I did not find, so please I accept suggestions. Here is the example: I have the receipt below where I wish to validate all the data in there: the origin and destination accounts (field ‘Conta’), the value transfered (field ‘Valor’), and all other relevant fields displayed in the receipt. So, I created the extension below: And I apply it in my tests as displayed in the image below: So, using this extension, I was able in a single running to validate all relevant data in my receipt. Does not matter if the first or third validation fails, the test will stop only after validate the last check. And at the end of a single running I will know all the fields that are OK or not. I hope that ideas can be useful to someone! Here is the repository, in case someone wants to analyse it: https://github.com/cristianorsilva/foradacaixac/tree/patrol_3.1.0 |
Beta Was this translation helpful? Give feedback.
Hi @s0leris, I raised the same question myself couple of months ago.
From my personal experience with Patrol the best approach is not to have a Page class for every screen in the app due to reduced device size. Instead of that I write a separate Page for a group of screens that are closely related to each other. If one screen has button that displays full screen timePicker widget there is no point in creating separate class for it.
If one Page starts to get too big I just split it. Reshaping POM takes a very little time - just write couple of tests the "plain" way and see for yourself which screens could be merged to avoid having one function Pages.
It's difficult to provide an example si…