Nightwatch.js 元素选择器重复使用的挑战
在nightwatch.js自动化测试脚本的编写过程中，开发者常常会遇到对同一页面元素执行多个操作时，需要反复指定其选择器的情况。例如，对一个元素先等待可见，然后点击，其代码可能如下所示：
browser
.waitForElementVisible('selector', 10000)
.click('THE SAME selector');这种重复不仅增加了代码量，降低了可读性，更重要的是，一旦元素的选择器发生变化，就需要修改多处代码，极大地影响了测试脚本的可维护性。一些其他测试框架（如Cypress）通过链式调用将元素选择和后续操作紧密结合，例如：
Cy
.get('element')
.should('be.visible')
.click();这使得元素选择器只需声明一次。那么，在Nightwatch.js中，我们如何实现类似的优化，避免选择器的重复定义呢？
Nightwatch.js 的设计哲学
Nightwatch.js之所以在元素操作的链式调用上与Cypress有所不同，源于其独特的设计哲学。Nightwatch.js允许所有命令进行链式调用，这意味着开发者可以构建更复杂、更灵活的测试流程。在这种设计下，每个命令（如 click、setValue 等）都需要明确知道其操作的目标元素。因此，即使是对同一元素执行多个操作，也需要在每个命令中重新指定选择器。
值得注意的是，Nightwatch.js 在执行某些操作（例如 click）时，通常会隐式地等待元素变得可见并可交互。这意味着在执行 click 命令之前，通常无需显式添加 assert.visible 或 waitForElementVisible，除非有特定的等待条件或断言需求。
尽管这种设计导致了选择器重复的问题，但Nightwatch.js提供了两种有效的策略来解决这一痛点。
解决方案一：使用变量存储选择器
最直接且简单的方法是将元素选择器存储在一个变量中。这适用于单个测试文件内，对特定元素进行多次操作的场景。通过将选择器定义为常量，可以在后续的命令中复用该变量，从而避免重复输入选择器字符串。
// 定义一个常量来存储GitHub按钮的选择器
const githubButton = 'a[aria-label="Nightwatch on Github"]';
describe('Nightwatch.js 元素选择器复用示例', function() {
// 在所有测试用例运行前导航到指定URL
before(browser => browser.navigateTo('https://nightwatchjs.org/'));
// 在所有测试用例运行后关闭浏览器
after(browser => browser.end());
it('点击GitHub按钮并验证', function (browser) {
browser
// 使用变量进行点击操作
.click(githubButton)
// 可以添加其他操作，例如验证页面URL是否跳转到GitHub
.assert.urlContains('github.com/nightwatchjs/nightwatch');
});
it('再次验证GitHub按钮是否存在', function(browser) {
browser
// 即使是不同的测试用例，也可以复用同一个变量
.assert.elementPresent(githubButton);
});
});这种方法简单易行，能够有效减少同一文件中选择器的重复。
解决方案二：Page Object 模式
对于大型或复杂的项目，Page Object（页面对象）模式是管理元素选择器和页面交互逻辑的更专业、更推荐的方法。Page Object 将页面的UI元素和与这些元素交互的方法封装在一个独立的类或对象中，从而实现：
- 提高可维护性： 当页面UI发生变化时，只需修改对应的Page Object文件，而无需修改所有引用该元素的测试用例。
- 增强可读性： 测试用例可以更专注于业务逻辑，而不是底层UI细节。
- 减少重复： 元素选择器和重复的交互逻辑（如登录流程）可以在Page Object中定义一次，并在多个测试用例中复用。
一个简单的Nightwatch.js Page Object结构示例：
// pages/homePage.js
const homePageCommands = {
/**
* 点击GitHub按钮
* @returns {object} 返回当前Page Object实例，以便链式调用
*/
clickGithubButton() {
return this.click('@githubButton');
},
/**
* 验证当前URL是否包含GitHub
* @returns {object} 返回当前Page Object实例
*/
assertUrlIsGithub() {
return this.assert.urlContains('github.com/nightwatchjs/nightwatch');
}
};
module.exports = {
url: 'https://nightwatchjs.org/', // 定义页面URL
commands: [homePageCommands], // 注册自定义命令
elements: {
githubButton: {
selector: 'a[aria-label="Nightwatch on Github"]', // 定义元素选择器
locateStrategy: 'css selector' // 可选，默认就是css selector
},
// 可以定义更多页面元素
searchBar: '#search-input',
submitButton: 'button[type="submit"]'
}
};然后在测试用例中，可以这样使用Page Object：
// tests/githubTest.js
describe('使用Page Object测试GitHub链接', function() {
// 声明使用homePage Page Object
const homePage = browser.page.homePage();
before(browser => homePage.navigate()); // 导航到Page Object定义的URL
after(browser => browser.end());
it('通过Page Object点击GitHub按钮并验证', function (browser) {
homePage
.clickGithubButton() // 调用Page Object中定义的方法
.assertUrlIsGithub(); // 调用Page Object中定义的断言方法
});
});通过Page Object模式，测试脚本变得更加抽象和易于管理。homePage.clickGithubButton() 这样的调用清晰地表达了测试意图，而无需关心具体的选择器细节。
最佳实践与考量
-
何时使用变量，何时使用Page Object？
- 变量： 适用于小型项目、单个测试文件内对少数元素进行操作的场景，或作为快速原型开发。
- Page Object： 强烈推荐用于中大型项目，当一个页面有多个元素或复杂的交互逻辑时。它能显著提升测试脚本的结构化、可维护性和可扩展性。
- 元素可见性： 如前所述，Nightwatch.js 的许多操作（如 click）在执行前会隐式等待元素可见。因此，通常不需要在Page Object或测试用例中显式添加 waitForElementVisible，除非有特定的异步加载或动画效果需要更长的等待时间。
- 选择器策略： 尽量使用稳定、不易变化的CSS选择器或XPath。避免使用依赖于动态生成的类名或ID的选择器。
- 代码组织： 将Page Object文件放置在项目结构中专门的 pages 目录下，与 tests 目录分离，保持项目清晰。
总结
Nightwatch.js 提供了灵活的机制来管理元素选择器，即使其链式调用模式与某些框架有所不同。通过将选择器存储为变量或更推荐地采用Page Object模式，开发者可以有效地避免选择器重复，提升测试脚本的可读性、可维护性和专业性。选择哪种方法取决于项目的规模和复杂性，但Page Object模式无疑是构建健壮、可扩展的Nightwatch.js自动化测试套件的基石。
