We are seeking for directions and we will be glad if you give us directions
According to the Page Object Model world, Page Object Model, also known as POM, is a design pattern in Selenium that creates an object repository for storing all web elements
things are supposed to be dependent on each other, so we are asking whether this is the right time to migrate all the pages and tests with in referenceapplication distro , utility methods in uitestframework i into single module qaframework to have one core module that is standalone.
Goals: Doing this kind of Task is very important and we will be approaching the design pattern of the Page Object Model .
It will be easy to maintain this module in future without having dependent on each any other module
Pain Points
Refactoring of all the tests and classes inheriting from these three modules
Another idea is that if we really decide to do this, we need to get rid of all the test classes and write them in form of cucumber style. As in have those tests written in a new test based workflow.
Write all the tests in qaframework inform of new based workflow, Note this does not necessary mean writing tests in E2e workflow , However write them following the same approach of how they have been written in current integration test.
Looking forward to have a more discussion about whether this is worth diving into irrespective of the limited availability time
Thanks to @dkayiwa@ibacher@kdaud who brought up in one of the reviews this but initially I had talked about it with @mozzy some time back though we didn’t have final resolutions.
Thanks @sharif for bringing this up here.
I think this is worthy diving into ,and ts actually something that actually doesnt require much effort. it could be a few days work.
I have always talked about this with you .
Its evident too many unnecessary dependencies were created leading to Redundancy and duplication of efforts ,and making the qa-framework harder to maintain.
For the start , we can just directly migrate every thing into the qa framework , and refactoring the tests(from the reff-app-distro) into the BDD style can be done slowly
Refactoring the three modules into one sounds to be a good deal however, there might be some history as to why contrib-uitestframework and distro-reference-application were made separate modules with distro depending on uitestframework. @ibacher@dkayiwa do you have any idea on this ?
My opinion would be combining pages and their respective test suits into one module. This would mean refactoring distro into qaframework so that we keep the utility methods in uitestframwork module. I’m thinking we can have the selenium legacy tests being in a folder and the tests following BDD approach also in another folder within the same module(qaframework).
Refactoring selenium legacy tests into BDD framework might not be worth diving into since the selenium legacy tests are performing the automation work as expected on every PR and on every merge. Refactoring these tests into BDD approach ideally implies the efforts that was done by the Team to resurrect all of them was not worth the work. And the question is, is this a priority if we are to refactor these two modules into one ? cc: @sharif@mozzy?
One thing we need to put in mind if we are to really dive into refactoring these modules into either one or two depending on what will be the better option is;
We have a lot of tasks on our table to work on as QA team so we need to concentrate our efforts on prioritized work, and the ones that are not of urgency can be worked on later!
In my understanding ,
Migrating the utils and Pages into the qa-framework requires less effort. probably one or two days .
This makes sense , and this will require some significant effort to refactor the Selenium tests into BDD style, so we can refrain from that at the moment
But i would go for migrating all the Utils and Pages from the ui-testframework and reff-app-distro into a single qa-framework module to make the framework easier to mainatin and raduce unnecesary effort duplication
Then why are we leaving out utility methods in uitestframework,Lets consider POM(page object model) Lets get rid of module dependency in this approach, Lets refactor everything we need in one single module which is qaframework.
i believe uitestframework has been there for some good time that’s why the new qaframework had only to depend on , Perhaps uitestframework have dependencies that we no longer use like saucelabs, I think this is where we might make it more cleaner and as @mozzy said , Easy to maintain .
I doubt there’s a good technical reason. I think the distro-reference-application started off as “a repo for all the things to do a release” and the tests there started off as the tests to confirm the release was good before letting things happen.
As long as whatever we end up with enables us to run the various UI tests against the same code as will be released before we release it, I don’t think it matters too much where the code lives (and I agree that having everything in a dedicated QA repository is probably desirable).
What’s the motivation for using the POM Selenium pattern? In my experience, it most often leads to an unmaintainable mess. It’s really hard to determine where the line should be between object class and test code.
Unless you have a clear sense that the current codebase is getting way out of hand and it seems obvious that POM is a strategy that would make it better, I wouldn’t bother.
Have tested all the workflows locally and all the tests are passing as expected, When this gets merged, we shall be writing all our automation in qaframework following the new BDD approach.
Then we shall create tickets for changing those selenium tests remained in distro into a new workflow. Thanks am requesting for reviews.
