如何不引入第三个变量交换两个变量的值?
2012-03-06 11:57
375 查看
Great points Mark, thanks. That will be a good reasoning of disadvantages to the approach.
Also wanted to point out though that going properties file approach, one doesn't have to lump all locators in a single properties file. You could split it up architecturally as you see fit. Same as whether you lump all Selenium code in a single class file or
break it up w/ OOP and/or page objects.
And on topic of page objects, at least from my collaborations, you can group locators for page together with the page methods/actions or split them up into separate files (there's no set in stone standard like with agile). And if you chose to keep them separate
in the page object design, you can then also implement with properties files with one property file mapped to each page object.
On Sunday, September 30, 2012 1:18:27 AM UTC-7, Mark Collin wrote:
I think a long list of locators hidden away in a property file is insane, you end up with long unreadable lists of rubbish. It may well look manageable at first but eventually it gets really long and anybody new looking at the codebase has to sit there
for hours trying to work out where everything links together. Secondly if you have a long list of locators hidden away in a properties file and you want to change the name of one of these properties you have refactoring hell (If you are using a decent modern
IDE like IntelliJ IDEA you can change the name of a variable in one place and it will change that name everywhere else for you). Keep it in the code is my recommendation.
What you should really do is use page objects. Page objects can be for a whole page, or you could split out a consistent bit of functionality into its own page object (for example if you have a header and menu bar that is consistent across the whole site
split it out into its own page object and reuse it in your other page objects).
At the end of the day there are many ways you can structure your data, but try and do something that makes it maintainable in the future and easy for new people who join the project to understand.
From:seleniu...@xxxxxxxxxxxxxxxx[mailto:seleniu...@xxxxxxxxxxxxxxxx]On
Behalf OfDavid
Sent:29 September 2012 07:45
To:seleniu...@xxxxxxxxxxxxxxxx
Subject:[selenium-users] Re: How to use values of properties file in selenium code
I think there is debate on the topic of whether it is good or bad, though the general consensus is to stay away from it. Personally, I think it really depends on how you structure & manage your test data & code which determines whether this will be useful
to you or not.
I personally would advocate it. I consider locators as a form of test data (though not of the same type as input data used to say type into text fields, etc.). If you look at it that way, then it is better to abstract it out of the test code and treated
as a "config" or properties and used similarly to data driven testing of being fetched from external source. Is also useful for changing locators w/o having to recompile the Java test code. But doing it this way, you loose integration of locators being matched
up with the test code/flow, in case that is needed, particularly say if combined with page objects.
And if you do use property files for locators, it becomes more useful if you abstract out the locatory type from code, so instead of
driver.findElement(By.cssSelector(OR.getProperty("loginButton"))).click();
you have something like this
driver.findElement(myUtilityClass.parseLocator(OR.getProperty("loginButton"))).click();
wheremyUtilityClass.parseLocator() is a custom class method you write that will figure out the locator type from what you pass into it and return appropriate By object. The figure out coudl be like matching against locator prefix for Selenium RC style locators,
in which case your property file would contain something like this
loginButton=css=someCssSelectorValue
emailAddress=xpath=someXpathValue
password=id=someIdValue
though of course I haven't done this myself, but that's how you would do it in theory, so callingOR.getProperty("loginButton") would return "css=someCssSelectorValue"
this approach also helps if you're migrating over from Selenium RC, so can keep RC locators intact, if they still work in WebDriver w/o modification of the values.
On Thursday, September 27, 2012 9:22:31 PM UTC-7, akki wrote:
Hey Syed, I was also considering the same approach to store my locators. Would you please elaborate on why it is not a good approach and which is a better approach.
--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email toseleniu...@xxxxxxxxxxxxxxxx.
To unsubscribe from this group, send email toselenium-user...@xxxxxxxxxxxxxxxx.
To view this discussion on the web visithttps://groups.google.com/d/msg/selenium-users/-/VZdgWKWVaWIJ.
For more options, visithttps://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to selenium-users@xxxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to selenium-users+unsubscribe@xxxxxxxxxxxxxxxxx
To view this discussion on the web visithttps://groups.google.com/d/msg/selenium-users/-/9rWYDoHw9DkJ.
For more options, visithttps://groups.google.com/groups/opt_out.
http://osdir.com/ml/selenium-users/2012-09/msg02103.html
Also wanted to point out though that going properties file approach, one doesn't have to lump all locators in a single properties file. You could split it up architecturally as you see fit. Same as whether you lump all Selenium code in a single class file or
break it up w/ OOP and/or page objects.
And on topic of page objects, at least from my collaborations, you can group locators for page together with the page methods/actions or split them up into separate files (there's no set in stone standard like with agile). And if you chose to keep them separate
in the page object design, you can then also implement with properties files with one property file mapped to each page object.
On Sunday, September 30, 2012 1:18:27 AM UTC-7, Mark Collin wrote:
I think a long list of locators hidden away in a property file is insane, you end up with long unreadable lists of rubbish. It may well look manageable at first but eventually it gets really long and anybody new looking at the codebase has to sit there
for hours trying to work out where everything links together. Secondly if you have a long list of locators hidden away in a properties file and you want to change the name of one of these properties you have refactoring hell (If you are using a decent modern
IDE like IntelliJ IDEA you can change the name of a variable in one place and it will change that name everywhere else for you). Keep it in the code is my recommendation.
What you should really do is use page objects. Page objects can be for a whole page, or you could split out a consistent bit of functionality into its own page object (for example if you have a header and menu bar that is consistent across the whole site
split it out into its own page object and reuse it in your other page objects).
At the end of the day there are many ways you can structure your data, but try and do something that makes it maintainable in the future and easy for new people who join the project to understand.
From:seleniu...@xxxxxxxxxxxxxxxx[mailto:seleniu...@xxxxxxxxxxxxxxxx]On
Behalf OfDavid
Sent:29 September 2012 07:45
To:seleniu...@xxxxxxxxxxxxxxxx
Subject:[selenium-users] Re: How to use values of properties file in selenium code
I think there is debate on the topic of whether it is good or bad, though the general consensus is to stay away from it. Personally, I think it really depends on how you structure & manage your test data & code which determines whether this will be useful
to you or not.
I personally would advocate it. I consider locators as a form of test data (though not of the same type as input data used to say type into text fields, etc.). If you look at it that way, then it is better to abstract it out of the test code and treated
as a "config" or properties and used similarly to data driven testing of being fetched from external source. Is also useful for changing locators w/o having to recompile the Java test code. But doing it this way, you loose integration of locators being matched
up with the test code/flow, in case that is needed, particularly say if combined with page objects.
And if you do use property files for locators, it becomes more useful if you abstract out the locatory type from code, so instead of
driver.findElement(By.cssSelector(OR.getProperty("loginButton"))).click();
you have something like this
driver.findElement(myUtilityClass.parseLocator(OR.getProperty("loginButton"))).click();
wheremyUtilityClass.parseLocator() is a custom class method you write that will figure out the locator type from what you pass into it and return appropriate By object. The figure out coudl be like matching against locator prefix for Selenium RC style locators,
in which case your property file would contain something like this
loginButton=css=someCssSelectorValue
emailAddress=xpath=someXpathValue
password=id=someIdValue
though of course I haven't done this myself, but that's how you would do it in theory, so callingOR.getProperty("loginButton") would return "css=someCssSelectorValue"
this approach also helps if you're migrating over from Selenium RC, so can keep RC locators intact, if they still work in WebDriver w/o modification of the values.
On Thursday, September 27, 2012 9:22:31 PM UTC-7, akki wrote:
Hey Syed, I was also considering the same approach to store my locators. Would you please elaborate on why it is not a good approach and which is a better approach.
--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email toseleniu...@xxxxxxxxxxxxxxxx.
To unsubscribe from this group, send email toselenium-user...@xxxxxxxxxxxxxxxx.
To view this discussion on the web visithttps://groups.google.com/d/msg/selenium-users/-/VZdgWKWVaWIJ.
For more options, visithttps://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to selenium-users@xxxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to selenium-users+unsubscribe@xxxxxxxxxxxxxxxxx
To view this discussion on the web visithttps://groups.google.com/d/msg/selenium-users/-/9rWYDoHw9DkJ.
For more options, visithttps://groups.google.com/groups/opt_out.
http://osdir.com/ml/selenium-users/2012-09/msg02103.html
相关文章推荐
- PHP中如何不引入第三个变量的条件下实现:交换两个变量的值?
- 用按位异或运算符交换两个数,不引入第三个变量
- 有没有意思,你说了算——不引入第三个变量交换两个整型数
- 有a、b两个变量,如何在不添加第三个变量的情况下,交换a、b变量的值?
- 声明两个变量:int n1=10,n2=20;要求将两个变量交换,最后输出n1为20,n2为10。扩展(*):不使用第三个变量如何交换?
- 交换两个数,不引入第三个变量
- 用按位异或运算符交换两个数,不引入第三个变量
- 不引进第三个变量,如何交换两个整型变量的值
- 不引入第三个变量交换两个变量的方法
- 不定义第三个变量,如何交换两个变量的值?
- C语言(如何不使用第三个变量达到交换两个变量值的目的)
- 不引入第三个变量交换两个整型数
- 不用第三个变量,如何交换两个变量的值
- 两个变量如何交换值
- 不借助第三个变量交换两个变量的值
- 不使用第三个变量交换两个int类型变量的值
- 不借助第三个变量,交换两个变量值的3种方式
- 不使用第三个变量交换两个变量的值,不同编译器的不同结果
- 【编程技巧】java不使用第三个变量处理两个变量的交换
- 不借助第三个变量来交换两个变量的值