在页面对象模型框架中存储数据的最佳方法是什么

Question

Im building an automation framework in selenium using the Page Object Design Pattern. Following are some of the data that Im using and where i have stored them

1. PageObjects (xpath, id etc) - In the Page Classes itself
2. Configuration Data (wait-times, browser type , the URL etc) - In a properties file.
3. Other data - In a class as static variables.
   

Once the framework starts growing it would be hard to store all the data it would be hard to organize the data. I did a some research on how others have implemented the way they store data in their framework. Here is what I found out,

1. Storing data (mostly page objects) in classes itself
2. Storing data in JSON
3. And some even suggested storing data in a database so that it would reduce reading times

Since there are lot of options out there, I thought of getting some feedback on what is the best way to store data and how everyone else has stored there data.

Answer 1

JSON或任何临时数据存储是最佳选择，因为它是一个框架，其目的是为不同项目重用。

Answer 2

I advice using Interfaces for each device type to store multiple type selectors, example:

import static org.openqa.selenium.By.cssSelector;
import static org.openqa.selenium.By.linkText;
import static org.openqa.selenium.By.xpath;

public interface DesktopMainPageSelector {
    By FIRST_ELEMENT = cssSelector("selector_here");
    By SECOND_ELEMENT = xpath("selector_here");
    By THIRD_ELEMENT = id("selector_here");
}

than, just implement these selectors from whatever you need them.

You can also use enums with for a more complex structure.

I found this as best solution, because its easy to manage large numbers of selectors

Answer 3

I don't see any problem with the way you have stored your data.

1. Locators (by POM definition) should be stored in the page objects themselves.
2. Config data can be stored in some sort of config file... whatever you find convenient. You can use plain text, JSON, XML, etc. We use XML but that really comes down to personal preference.
3. I think this is fine also.

The framework doesn't really grow, the automation suite does. As long as you keep the data stored in the 3 places above consistently, I think you should be fine. The only issue I've run into with this approach is that sometimes certain pages have a LOT of functionality on them so the page objects grow quite large. In those cases, we found a way to divide the page into smaller chunks, eg one page had 22 tabs, each consisting of a different panel. In that case, we broke the page object into 22 different class files to keep the size more manageable and then hooked them all back into the main page as properties, eg mainPage.Panel1.someMethodOnPanel1();