Requesting name and/or id for better Selenium testability
I'm testing an application using Cucumber + Java + Selenium and I'm seeing that, most of the type, elements don't have a name, nor an id.
This is the case for almost every component on the page but, more importantly, it's the case for clickable elements which make life harder for me (since I can't do a findElement(By.id(myId))
and have to be creative with my use of XPath).
I'm thinking about asking the dev to add an id or a name to every clickable element and to not clickable element that changes depending on what you have entered before.
Question
Am I abusing my powers here? If not, what argument can I use to make them see that it's a valid request?
automated-testing browser-automation
New contributor
add a comment |
I'm testing an application using Cucumber + Java + Selenium and I'm seeing that, most of the type, elements don't have a name, nor an id.
This is the case for almost every component on the page but, more importantly, it's the case for clickable elements which make life harder for me (since I can't do a findElement(By.id(myId))
and have to be creative with my use of XPath).
I'm thinking about asking the dev to add an id or a name to every clickable element and to not clickable element that changes depending on what you have entered before.
Question
Am I abusing my powers here? If not, what argument can I use to make them see that it's a valid request?
automated-testing browser-automation
New contributor
add a comment |
I'm testing an application using Cucumber + Java + Selenium and I'm seeing that, most of the type, elements don't have a name, nor an id.
This is the case for almost every component on the page but, more importantly, it's the case for clickable elements which make life harder for me (since I can't do a findElement(By.id(myId))
and have to be creative with my use of XPath).
I'm thinking about asking the dev to add an id or a name to every clickable element and to not clickable element that changes depending on what you have entered before.
Question
Am I abusing my powers here? If not, what argument can I use to make them see that it's a valid request?
automated-testing browser-automation
New contributor
I'm testing an application using Cucumber + Java + Selenium and I'm seeing that, most of the type, elements don't have a name, nor an id.
This is the case for almost every component on the page but, more importantly, it's the case for clickable elements which make life harder for me (since I can't do a findElement(By.id(myId))
and have to be creative with my use of XPath).
I'm thinking about asking the dev to add an id or a name to every clickable element and to not clickable element that changes depending on what you have entered before.
Question
Am I abusing my powers here? If not, what argument can I use to make them see that it's a valid request?
automated-testing browser-automation
automated-testing browser-automation
New contributor
New contributor
New contributor
asked 2 days ago
NoonNoon
1263
1263
New contributor
New contributor
add a comment |
add a comment |
5 Answers
5
active
oldest
votes
This is a perfectly fine request. If the QA department decided to use primarily id
locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id
locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id
are basically bugs, because they are expected to have an id
for testing purposes.
As for arguments for implementing id
s on elements...:
- If the specification says the feature should be tagged with
id
s where neccessary, and there are noid
s, it's a bug and should be treated as so. - You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than
id
s. I honestly don't think that the costs accured during tagging of elements withid
s would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide. - It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With
id
s however, when you have e.g. a contact form, chances are there is always going to be something like<button id="send-message">Send</button>
, no matter how many fields are in the form or in what section the contact form is. - It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
add a comment |
It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.
add a comment |
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
div
is changed tospan
- an additional
div
will be added to the structure - a
class
name is changed or an additionalclass
is introduced - etc.
All in these cases the tests should be updated, on the other hand if there would have been a proper id
assigned to the tested elements, the tests would work fine without any action.
add a comment |
An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.
If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.
xpath = "//label[text() = 'Print Book']"
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
add a comment |
There are at least few things which you can gain by requesting that.
- The test will run faster (finding by id is faster than looking through xpath)
- The tests won't fail that much when the UI will change, and time to maintain them will be shorter
There are also few things which can make your request not doable:
- When items on page are generated automatically (and cannot be named statically).
- Developer will need too much time to do that
- If the framework / language in which site is done doesn't support that.
So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "244"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
Noon is a new contributor. Be nice, and check out our Code of Conduct.
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%2fsqa.stackexchange.com%2fquestions%2f37253%2frequesting-name-and-or-id-for-better-selenium-testability%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a perfectly fine request. If the QA department decided to use primarily id
locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id
locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id
are basically bugs, because they are expected to have an id
for testing purposes.
As for arguments for implementing id
s on elements...:
- If the specification says the feature should be tagged with
id
s where neccessary, and there are noid
s, it's a bug and should be treated as so. - You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than
id
s. I honestly don't think that the costs accured during tagging of elements withid
s would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide. - It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With
id
s however, when you have e.g. a contact form, chances are there is always going to be something like<button id="send-message">Send</button>
, no matter how many fields are in the form or in what section the contact form is. - It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
add a comment |
This is a perfectly fine request. If the QA department decided to use primarily id
locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id
locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id
are basically bugs, because they are expected to have an id
for testing purposes.
As for arguments for implementing id
s on elements...:
- If the specification says the feature should be tagged with
id
s where neccessary, and there are noid
s, it's a bug and should be treated as so. - You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than
id
s. I honestly don't think that the costs accured during tagging of elements withid
s would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide. - It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With
id
s however, when you have e.g. a contact form, chances are there is always going to be something like<button id="send-message">Send</button>
, no matter how many fields are in the form or in what section the contact form is. - It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
add a comment |
This is a perfectly fine request. If the QA department decided to use primarily id
locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id
locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id
are basically bugs, because they are expected to have an id
for testing purposes.
As for arguments for implementing id
s on elements...:
- If the specification says the feature should be tagged with
id
s where neccessary, and there are noid
s, it's a bug and should be treated as so. - You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than
id
s. I honestly don't think that the costs accured during tagging of elements withid
s would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide. - It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With
id
s however, when you have e.g. a contact form, chances are there is always going to be something like<button id="send-message">Send</button>
, no matter how many fields are in the form or in what section the contact form is. - It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
This is a perfectly fine request. If the QA department decided to use primarily id
locators for testing (as combining several locator types is difficult to maintain) and the developers agreed to this, front-end feature implementations without id
locators shouldn't pass through QA successfully, because they do not follow the set standards. Current elements without id
are basically bugs, because they are expected to have an id
for testing purposes.
As for arguments for implementing id
s on elements...:
- If the specification says the feature should be tagged with
id
s where neccessary, and there are noid
s, it's a bug and should be treated as so. - You are a business. You are supposed to find solutions with the biggest reward/cost ratio. XPaths are slower and harder to implement in tests than
id
s. I honestly don't think that the costs accured during tagging of elements withid
s would outweigh the overall costs of using XPaths in testing. However, this is something the project manager should decide. - It allows you to create more maintainable tests and reduces the amount of false positives. DOM changes much more often than the general layout and design of the frontend. With
id
s however, when you have e.g. a contact form, chances are there is always going to be something like<button id="send-message">Send</button>
, no matter how many fields are in the form or in what section the contact form is. - It makes life easier for both of you. You will be able to write better tests faster, so you can dedicate more time to other types of testing, such as exploratory testing, finding more bugs. The developers in turn get quicker feedback and will be able to fix bugs quicker.
edited yesterday
answered 2 days ago
lostInCodelostInCode
1612
1612
add a comment |
add a comment |
It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.
add a comment |
It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.
add a comment |
It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.
It is a normal practice. You should only remember that in modern UI a lot of elements are dynamically generated so the capabilities of your devs might be limited in that area. It might also depend on the particular framework your devs use for building UI.
answered 2 days ago
Alexey R.Alexey R.
6,6021728
6,6021728
add a comment |
add a comment |
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
div
is changed tospan
- an additional
div
will be added to the structure - a
class
name is changed or an additionalclass
is introduced - etc.
All in these cases the tests should be updated, on the other hand if there would have been a proper id
assigned to the tested elements, the tests would work fine without any action.
add a comment |
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
div
is changed tospan
- an additional
div
will be added to the structure - a
class
name is changed or an additionalclass
is introduced - etc.
All in these cases the tests should be updated, on the other hand if there would have been a proper id
assigned to the tested elements, the tests would work fine without any action.
add a comment |
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
div
is changed tospan
- an additional
div
will be added to the structure - a
class
name is changed or an additionalclass
is introduced - etc.
All in these cases the tests should be updated, on the other hand if there would have been a proper id
assigned to the tested elements, the tests would work fine without any action.
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
div
is changed tospan
- an additional
div
will be added to the structure - a
class
name is changed or an additionalclass
is introduced - etc.
All in these cases the tests should be updated, on the other hand if there would have been a proper id
assigned to the tested elements, the tests would work fine without any action.
answered 2 days ago
Bence KaulicsBence Kaulics
600216
600216
add a comment |
add a comment |
An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.
If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.
xpath = "//label[text() = 'Print Book']"
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
add a comment |
An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.
If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.
xpath = "//label[text() = 'Print Book']"
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
add a comment |
An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.
If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.
xpath = "//label[text() = 'Print Book']"
An alternative is to attempt to base your selectors on the text visible to the users, via Xpaths. Then it does not matter if the location of an element changes, the size or color or any other aspect other then the visible text.
If this turns out to be difficult for some cases, then by all means ask for a specific ID for a specific element. But the point is for the majority of cases you probably won't need to do that.
xpath = "//label[text() = 'Print Book']"
edited 2 days ago
answered 2 days ago
Paul Collingwood - FutrliPaul Collingwood - Futrli
763
763
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
add a comment |
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
Then pick your targets. If things are changing often, don't attempt to test them like this. Wait until they are stable (i.e. signed off) and then test them. Automated tests cannot be maintained against constant change easily.
– Paul Collingwood - Futrli
2 days ago
add a comment |
There are at least few things which you can gain by requesting that.
- The test will run faster (finding by id is faster than looking through xpath)
- The tests won't fail that much when the UI will change, and time to maintain them will be shorter
There are also few things which can make your request not doable:
- When items on page are generated automatically (and cannot be named statically).
- Developer will need too much time to do that
- If the framework / language in which site is done doesn't support that.
So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)
add a comment |
There are at least few things which you can gain by requesting that.
- The test will run faster (finding by id is faster than looking through xpath)
- The tests won't fail that much when the UI will change, and time to maintain them will be shorter
There are also few things which can make your request not doable:
- When items on page are generated automatically (and cannot be named statically).
- Developer will need too much time to do that
- If the framework / language in which site is done doesn't support that.
So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)
add a comment |
There are at least few things which you can gain by requesting that.
- The test will run faster (finding by id is faster than looking through xpath)
- The tests won't fail that much when the UI will change, and time to maintain them will be shorter
There are also few things which can make your request not doable:
- When items on page are generated automatically (and cannot be named statically).
- Developer will need too much time to do that
- If the framework / language in which site is done doesn't support that.
So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)
There are at least few things which you can gain by requesting that.
- The test will run faster (finding by id is faster than looking through xpath)
- The tests won't fail that much when the UI will change, and time to maintain them will be shorter
There are also few things which can make your request not doable:
- When items on page are generated automatically (and cannot be named statically).
- Developer will need too much time to do that
- If the framework / language in which site is done doesn't support that.
So basically the best approach would be talking to developer and asking him about how much of naming can he do by himself (or show you how to add those names / ids by yourself.)
answered yesterday
Michal DobrzyckiMichal Dobrzycki
865
865
add a comment |
add a comment |
Noon is a new contributor. Be nice, and check out our Code of Conduct.
Noon is a new contributor. Be nice, and check out our Code of Conduct.
Noon is a new contributor. Be nice, and check out our Code of Conduct.
Noon is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Software Quality Assurance & Testing Stack Exchange!
- 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%2fsqa.stackexchange.com%2fquestions%2f37253%2frequesting-name-and-or-id-for-better-selenium-testability%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