8

Well, first I would ask these questions: Do you really need to write Selenium test for all of these 500 pages? Do your developers write enough and good Unit tests? I assume it is a Single Page Application and for sure there are so many common components between these 500 pages i.e they are not 500 unique pages with completely different behaviours and ...


8

Page Object and Selenium's PageFactory are distinct things in nature, usually the latter complement the former. Page Object is a design pattern aimed at solving the problem of separating the application interface from the HTML interface. Why do we separate these interfaces? Because web pages elements and functions, as saw by the user, differ from the HTML ...


6

I wouldn't say the PoM pattern is intended to model a behavior. Rather a user interface. Tests are intended to model behavior. If you have your object less abstract then you can assert the results more precisely. Having just a login method wouldn't let you assert the things which happens inside login. We'll, technically you'll be able to but asserting ...


5

To answer your questions: You are correct in that Page Objects are classes and inheriting from a base/parent class is good. When it comes to selectors, the most common option is to have them be variables. When I create frameworks like this, all my selectors are private variables so that only the Page Object class knows about those selectors. Depending on ...


5

When I think how to design a test framework I always ask myself if the code I am writing would be easy to understand by someone else in 6 months. That is why I would suggest to keep it as simple as possible. Since we are talking about a small amount of test cases that will deal with the timeout, you can implement timeout specifc functions inside ...


5

I think if you stick to simple PageObjects as described by Martin Fowler it is fine. It should be a simple abstraction to keep your test-code DRY, reusable and increase readability by using page-methods that describe behaviour of the page/view. The linked article is mainly about issues with Page Factories and thinking PageObjects have to return another Page ...


5

THINK BIG; We are going to automate everything! I am so excited! act small; Automate a single user flow. (Not login, but a real end-to-end behaviour, login might be part of this.) Fail fast; Struggle... Learn rapidly; Retrospect, inspect and adapt, decide on the next experiment and goto act small. I love simple PageObjects as pattern. Not as a "framework". ...


4

The conclusion that She says that POM leads to excess code and maintainability issues. is wrong. Page Objects is a a concept that can be implemented in many ways. They solve two simple problems: They reduce duplication DRY is usually good They name stuff One of the two hard problems in computer science They reduce maintainability issues - the exact ...


4

As with any piece of software, you can consider a few heuristics when deciding abstractions: 1 - On a higher-level abstraction, Single Responsibility Principle: A component (method, class, module) should serve a single actor. Meaning that a component should change for a single reason. E.g., if you have a HomePage object that has loginand goToAboutPage, ...


3

The choice of such design lies mainly on the product under test, tool, and the language you use. My personal preference is to: Add it in Page objects if it's being reused many times If it's just for 1 test case then, have it in the test suite itself. The reason for following the practice of not having assertions in page objects was to promote easy ...


3

For the test infrastructure code (helper and utility classes, custom logic, etc) - unit testing might make sense in case if you are providing your framework to a 3rd party usage (that can be a community in case of opensource or even the other team within your organization). Approach it as a regular code and follow the common unit testing approaches. For the ...


3

I will not go into the details of what the problems are regarding Page Objects, there are lot's of articles on the net by people who put in more thought than me. From my experience though I would go with https://johnfergusonsmart.com/beyond-page-objects-liberate-chains-ui-think/ in saying: page objects are fine but another level of abstraction is helpful ...


3

Do you really want to test that the text Welcome is there? You say the identifiers are dynamic. In these situations, I always suggest to talk to the developers and make it better testable. Preferably developers and testers write and maintain the end-to-end tests together. Let them feel your pain. Now when in application developer change welcome to ...


3

I might choose option A and do what is needed when it is needed without the extra abstraction. One additional option is also to move away from a strict page object model. My reason for doing this is maintainability. The issue I encounter is the knowledge needed (or gained) for the page breakdown. You'll often find components that are: Universal, e.g. a '...


3

Both of your options listed can work. Though, as you mentioned, option A is only slightly better than not using POM. Every time I do test automation, it's always been on teams that have no automation, so I'm always creating frameworks from scratch. In my experience, I favor option B that you have listed. This level of abstraction and encapsulation works ...


3

There aren't any hard rules when it comes to writing Page Object Model or any test Framework. The key is to identify the approach that makes it reusable, easy to understand , and less maintenance effort. Some of the procedures i follow are: Should i bother writing a wrapper function like login? Why to bother having login function if it is not used in ...


3

I like to take it one step further and also make abstractions for test-data like a user. login(user) { this.setEmail(user.email); this.setPassword(user.password); this.submit(); } This userObject could check if it exists, setup itself. I dont like to hardcode things like passwords in the test. Follow clean code princibles when splitting ...


2

Page objects are a classic example of encapsulation - they hide the details of the UI structure and widgetry from other components (the tests). It's a good design principle to look for situations like this as you develop - ask yourself "how can I hide some details from the rest of the software?" https://martinfowler.com/bliki/PageObject.html I ...


2

Like a lot of things in life, it depends. Both options you lay out will work for test automation. However, what is your overall goal? Are you testing a feature that is on one page? If so, you can load that page directly and test that feature. This is what you listed as option 1. Are you testing a feature integration point, like a page redirect? Are you ...


2

Fair warning: this is my opinion based on practice: if it does what you need and doesn't introduce too much of a maintenance burden, it's not bad practice. Your goal is to build scripts that a relatively easy to extend, relatively easy to debug, and relatively easy to maintain. If capybara works for you, then it's good.


2

I never really used protractor, but I built some tests in JavaScript. I would prefer the second one, as it does not have this this this everywhere. I think it is more readable. You can also wrap it in a function again to make it a bit more descriptive, and so you can include a sort of private methods. I structured my JavaScript tests like this: const ...


2

A check usually follows the Setup-Act-Check pattern. In the setup, you put the environment in the minimal state relevant for your check, including your test data. Let's consider a form that have 3 sections and a few fields on each. Your test could be some of this sort: FormPage form = FormPage() FormData data = FormData("some_test_data_file.json") form....


2

In my experience, it is best to put the waits in the Page Objects. The purpose of the waits are to wait for an element to be displayed or to have the page finished loading, etc (depending on the wait you are using). Using POM, all your elements are in the page object and you write methods that utilize those elements also in the page object. Given this, you ...


2

Try to change @FindBy(xpath = "a[@class='HeaderMenu-link no-underline mr-3']") private WebElement signInBtn; to @FindBy(xpath = "//a[@class='HeaderMenu-link no-underline mr-3']") private WebElement signInBtn; Two slashes are missing before a.


1

I think you are forgeting to init the Elements and try to click on an element that is still null. Add something like this to the constructor of the page PageFactory.initElements(driver, this); Something like: public MainPage(WebDriver driver){ this.driver = driver; PageFactory.initElements(driver, this); } Look at this question for an example: ...


1

Technology wise it depends on who might use it, we have developed test suites with protractor but they are rule out because there are no many automation tester who are adept with javascript. Go with the technology you or your team feel more comfortable with. edit: misread the question.


1

As a simple answer to your question: Page Objects scale well. And more on the guidance side of things... Should you be testing 500 variations on the same pages using 500 unique page objects? No, probably not. A set of pages that allow tests to check what features are enabled on the page at a given time would be a more sensible way to handle this. E.g. ...


1

Judging by this: Java.lang.NullPointerException at java.io.FileInputStream.(Unknown Source) at java.io.FileInputStream.(Unknown Source) at com.mercury.qa.base.BaseTest.(BaseTest.java:26) at com.mercury.qa.testcase.LoginPageTest.(LoginPageTest.java:18) ... 26 more } The properties file cannot be found - you should fix the path, or create a ...


1

I'd say your option 3 is the approach I would go for with a few differences. Since selenium tests are supposed to represent specific scenarios, avoid making your objects too clever. In my opinion you should know exactly what you're trying to do when a method is called. In this case, there should be no check in the method to see if you get redirected or not. ...


1

The page object model is a design pattern that describes the best approach for modeling a test automation framework when it comes to web automation. The @FindBy() annotation is just a shortcut provided to developers by the PageFactory class. Use of the @FindBy() annotation is not mandatory for you to use the page object principles. You can still model your ...


Only top voted, non community-wiki answers of a minimum length are eligible