Hi all,
I work with a web-based technology that uses a lot of modals.
Currently we have them set up to just exist in the Page Object Class, but I was wondering if they should be separate instead?
1 Like
When you say that they exist in page object classes, I think that means that they are in separate “page” classes.
Please clarify your question maybe.
1 Like
What I mean to say is it is set out so that we do not have modals exist as objects themselves, they are controlled by a set of methods within the Page Object Class that the modal will appear in
e…g
PageObjectClase {
// Methods relating to Page
// Set of methods relating to Modal
}
1 Like
IMO the priority should always be the maintanability of the framework, instead of strictly enforcing patterns.
Do all those modals only appear on that specific page? If so, it’s easier to remember where they are by putting them directly in that page’s class, instead of looking for specific classes for each one.
But if they appear on more than one page, it becomes harder to remember that a specific modal is inside page Y’s class, rather than in the page I’m currently testing. In that case it’s better to have a separate class for each one.
2 Likes
It’s good idea to start from the beginning: what are you trying to achieve? Is there a problem? What and why? Why are you considering changing the current setup? What costs there are right now and what benefits do you hope to see?
Modals are a single component in frontend code, hopefully. So it makes sense for them to be a single component in your testing code, too. Ideally you would have a single locator in single place to find a button closing a modal, because for all intents and purposes, it is single element.
So you might have a single class representing modal, and that class would have methods for confirming, cancelling, closing etc.
Depending on how you write your test code, these methods may or may not be provided to tests. They might as well be hidden inside page object as implementation details.
Welcome to the most awesome online software testing community in the entire known universe. Great question.
For me perhaps the biggest reason to take modals out of the POM objects they get used in is that in the client implementation, those modals might also be separate modules or pages. You will then be able to look at all modal test code in isolation, and refactor it or even detect inconsistencies across the product by looking at them separately from and not hidden away inside another POM.
You will be decomposing slightly so it might seem like it costs more to pull the modals out into separate units, and be more declarative, and thus more “testable”. Maintainability will be better, and while modals very infrequently move to different pages, if they do, then it becomes a one-liner change, so you get lower product-change resistance (friction) and fragility in your tests.