Mixing
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
asked Jan 10 at 9:34
NoonNoon
1413
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
asked Jan 10 at 9:34
NoonNoon
1413
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
asked Jan 10 at 9:34
NoonNoon
1413
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
asked Jan 10 at 9:34
NoonNoon
1413
asked Jan 10 at 9:34
NoonNoon
1413
asked Jan 10 at 9:34
NoonNoon
1413
asked Jan 10 at 9:34
NoonNoon
1413
asked Jan 10 at 9:34
NoonNoon
1413
1413
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 ids on elements...:
- If the specification says the feature should be tagged with
ids where neccessary, and there are noids, 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
ids. I honestly don't think that the costs accured during tagging of elements withids 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
ids 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.
answered Jan 10 at 10:16
lostInCodelostInCode
1612
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.
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
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
divis changed tospan - an additional
divwill be added to the structure - a
classname is changed or an additionalclassis 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 Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
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']"
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
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
Jan 10 at 16:15
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.)
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
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
});
}
});
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 ids on elements...:
- If the specification says the feature should be tagged with
ids where neccessary, and there are noids, 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
ids. I honestly don't think that the costs accured during tagging of elements withids 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
ids 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.
answered Jan 10 at 10:16
lostInCodelostInCode
1612
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 ids on elements...:
- If the specification says the feature should be tagged with
ids where neccessary, and there are noids, 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
ids. I honestly don't think that the costs accured during tagging of elements withids 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
ids 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.
answered Jan 10 at 10:16
lostInCodelostInCode
1612
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 ids on elements...:
- If the specification says the feature should be tagged with
ids where neccessary, and there are noids, 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
ids. I honestly don't think that the costs accured during tagging of elements withids 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
ids 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.
answered Jan 10 at 10:16
lostInCodelostInCode
1612
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 ids on elements...:
- If the specification says the feature should be tagged with
ids where neccessary, and there are noids, 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
ids. I honestly don't think that the costs accured during tagging of elements withids 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
ids 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.
answered Jan 10 at 10:16
lostInCodelostInCode
1612
edited Jan 11 at 14:50
answered Jan 10 at 10:16
lostInCodelostInCode
1612
answered Jan 10 at 10:16
lostInCodelostInCode
1612
answered Jan 10 at 10:16
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.
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
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.
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
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.
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
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 Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
answered Jan 10 at 10:19
Alexey R.Alexey R.
7,1141729
7,1141729
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
divis changed tospan - an additional
divwill be added to the structure - a
classname is changed or an additionalclassis 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 Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
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
divis changed tospan - an additional
divwill be added to the structure - a
classname is changed or an additionalclassis 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 Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
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
divis changed tospan - an additional
divwill be added to the structure - a
classname is changed or an additionalclassis 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 Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
The more complex is an xPath expression the more likely that it will be broken somewhere in the future. For example:
- a
divis changed tospan - an additional
divwill be added to the structure - a
classname is changed or an additionalclassis 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 Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
answered Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
answered Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
answered Jan 10 at 11:55
Bence KaulicsBence Kaulics
680217
680217
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']"
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
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
Jan 10 at 16:15
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']"
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
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
Jan 10 at 16:15
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']"
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
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']"
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
edited Jan 10 at 16:15
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
answered Jan 10 at 13:52
Paul Collingwood - FutrliPaul Collingwood - Futrli
764
764
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
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
Jan 10 at 16:15
add a comment |
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
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
Jan 10 at 16:15
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
But what if the text change? I'm testing a beta version and the text changing is really not unlikely.
– Noon
Jan 10 at 14:17
1
1
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
Jan 10 at 16:15
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
Jan 10 at 16:15
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.)
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
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.)
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
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.)
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
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 Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
answered Jan 11 at 13:39
Michal DobrzyckiMichal Dobrzycki
3106
3106
add a comment |
add a comment |
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
