@FindBy(css="a[name='bcrumb']") protected List<WebElement> breadCrumbLinks; @FindBy(id="skuError") protected WebElement skuError; @FindBy(className="reducedPrice") protected List<WebElement> reducedPrice; @FindBy(partialLinkText="Injinji RUN 2.0") protected WebElement playButton; @FindBy(linkText="annual member refund") protected WebElement annualMemberrefund; @FindBy(xpath="//li[@itemprop='price']") protected WebElement productPrice;
根据定义,@FindBy可以使用以下命令找到一个选择器：using,id,name,className,css,tagName,linkText,partialLinkText和xpath.
最近,我们的前端开发人员建议我们实现一个以’test =’开头的新属性类.我认为这是一个好主意,因为我们可以通过查找文本的文本来找到WebElements,而不是@FindBy本身使用的值.我的问题是,最好是扩展@FindBy OR的现有功能,创建一种搜索我们在测试中使用的WebElements的新方式吗？
解决方法
我不会花费自定义属性的努力,除非你不能使用现有的方法.我更喜欢在可能的情况下使用现有的定位器(查找逻辑).
只要有可能,使用ID属性.如果页面是有效的HTML,那么ID在页面上是唯一的.它们在每个浏览器中的分辨率都非常快,UI可以大大改变,但脚本仍然可以定位元素.
有时,ID不是正确的选择.当您使用像网格控件这样的东西时,动态生成的ID几乎总是错误的选择.你依靠一个可能与特定行位置相关联的身份证件,然后如果你的行发生变化,那么你就会被钉住.
在其中一些情况下,您的开发人员可以通过将动态生成的ID值附加或保留常量值来帮助您. ASP.NET Webforms使用动态生成的值来创建疯狂的东西,所以我已经使用了一个后缀我的好几次.
链接文本,名称属性值和CSS选择器(JQuery样式)是很好的第二选择,当您无法获得稳定,可靠的ID或只是不可用.
XPath是我几乎所有情况下的最后选择.它很慢,可以非常脆弱,当它是一个复杂的XPath时很难处理.也就是说,如果您需要上下移动定位器的DOM页面,那么这是唯一的选择.
使用现有的FindBy方法之一意味着您将使用一个知名的,良好支持的定位器策略.这是一个很大的好处,当你试图找出一个旧的测试,或者当一个新人加入你的团队.
那是我的0.02美元