POM Model Data and Locator Locations
When testing using the POM model data pattern, is it best to have the locators for elements in the page object or have them in a separate file like the test data
pageObject
loginPage
homePage
testDate
loginPageData
homePageData
pageLocators
loginPageLocators
homePageLocators
specs
loginTest.js
Many thanks
javascript testing jasmine protractor
asked Nov 12 '18 at 14:58
user3389610user3389610
115
add a comment |
When testing using the POM model data pattern, is it best to have the locators for elements in the page object or have them in a separate file like the test data
pageObject
loginPage
homePage
testDate
loginPageData
homePageData
pageLocators
loginPageLocators
homePageLocators
specs
loginTest.js
Many thanks
javascript testing jasmine protractor
asked Nov 12 '18 at 14:58
user3389610user3389610
115
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20
add a comment |
When testing using the POM model data pattern, is it best to have the locators for elements in the page object or have them in a separate file like the test data
pageObject
loginPage
homePage
testDate
loginPageData
homePageData
pageLocators
loginPageLocators
homePageLocators
specs
loginTest.js
Many thanks
javascript testing jasmine protractor
asked Nov 12 '18 at 14:58
user3389610user3389610
115
When testing using the POM model data pattern, is it best to have the locators for elements in the page object or have them in a separate file like the test data
pageObject
loginPage
homePage
testDate
loginPageData
homePageData
pageLocators
loginPageLocators
homePageLocators
specs
loginTest.js
Many thanks
javascript testing jasmine protractor
javascript testing jasmine protractor
asked Nov 12 '18 at 14:58
user3389610user3389610
115
asked Nov 12 '18 at 14:58
user3389610user3389610
115
asked Nov 12 '18 at 14:58
user3389610user3389610
115
asked Nov 12 '18 at 14:58
user3389610user3389610
115
asked Nov 12 '18 at 14:58
user3389610user3389610
115
115
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20
add a comment |
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20
add a comment |
1 Answer
1
active
oldest
votes
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
- to find a failed line in a spec and jump in the source code of the method that causes error
- This method belongs to extended class and depends on parental class, so I jump in the source of the class
- That method interacts with an element, defined somewhere else, so I have to open that file
- the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53264784%2fpom-model-data-and-locator-locations%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
- to find a failed line in a spec and jump in the source code of the method that causes error
- This method belongs to extended class and depends on parental class, so I jump in the source of the class
- That method interacts with an element, defined somewhere else, so I have to open that file
- the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
add a comment |
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
- to find a failed line in a spec and jump in the source code of the method that causes error
- This method belongs to extended class and depends on parental class, so I jump in the source of the class
- That method interacts with an element, defined somewhere else, so I have to open that file
- the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
add a comment |
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
- to find a failed line in a spec and jump in the source code of the method that causes error
- This method belongs to extended class and depends on parental class, so I jump in the source of the class
- That method interacts with an element, defined somewhere else, so I have to open that file
- the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
- to find a failed line in a spec and jump in the source code of the method that causes error
- This method belongs to extended class and depends on parental class, so I jump in the source of the class
- That method interacts with an element, defined somewhere else, so I have to open that file
- the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
answered Nov 13 '18 at 4:18
Sergey PleshakovSergey Pleshakov
200113
200113
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
add a comment |
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
Thanks for your incite. I was worried about trying to split thing up to much.
– user3389610
Nov 13 '18 at 10:18
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53264784%2fpom-model-data-and-locator-locations%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Page object is place for locators
– John Peters
Nov 12 '18 at 15:20