Protractor - Style Guide For Protractor

在本章中,让我们详细了解导师的风格指南。

Introduction

风格指南由2名软件工程师(Carmen Popoviciu)创建,前线工程师(ING)和Andres Dominguez(谷歌软件工程师)。 因此,这一风格指南也称为Carmen Popoviciu和谷歌的导体指南。

这一风格指南可分为以下五点:

Generic rules

Project Structure

Locator strategies

Page Objects

Test suites

Generic Rules

下面是一些通用规则,在使用探测器进行测试时必须予以注意——

Do not end-to-end test what has been already unit tested

这是Carmen和Andres提出的第一个通用规则。 他们建议,我们不能对已经经过测试的法典进行电子2测试。 其主要原因是单位测试比电子2测试快得多。 另一个原因是,我们必须避免重复测试(登机既进行单位测试,又进行电子测试),以拯救我们的时间。

Use only one configuration file

建议的另一个重要点是,我们必须只使用一个配置文件。 不要为你们正在测试的每一种环境建立配置文件。 您可使用 主动-protractor-coverage,以便建立不同的环境。

Avoid using logic to your test

我们必须避免在我们试验案例中使用国际红十字与红新月联会的声明或圈子,因为如果我们这样做的话,试验可能不经试验而通过,或者可能非常缓慢。

Make the test independent at file level

如果能够分享,教员可以同时进行试验。 这些档案一旦获得,就由不同的浏览器执行。 Carmen和Andres建议至少使测试在档案一级独立,因为由原告管理的命令不确定,而且很容易单独进行测试。

Project Structure

指导者风格指南的另一个重要要点是贵项目的结构。 以下是关于项目结构的建议:

Groping e2e test in a sensible structure

Carmen和Andres建议,我们必须把我们的电子2e测试归入对贵项目结构具有意义的结构。 这项建议背后的原因是,查找档案会变得容易,文件夹层结构将更易阅读。 这一步骤还将将电子2e检测与单位测试分开。 他们建议避免以下结构:

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         home-page.js
         home-spec.js
         profile-page.js
         profile-spec.js
         contacts-page.js
         contacts-spec.js

另一方面,他们建议建立以下结构:

|-- project-folder
   |-- app
      |-- css
      |-- img
      |-- partials
         home.html
         profile.html
         contacts.html
      |-- js
         |-- controllers
         |-- directives
         |-- services
         app.js
         ...
      index.html
   |-- test
      |-- unit
      |-- e2e
         |-- page-objects
            home-page.js
            profile-page.js
            contacts-page.js
         home-spec.js
         profile-spec.js
         contacts-spec.js

Locator Strategies

下面是一些定位战略,在使用探测器进行检测时必须予以注意——

Never use XPATH

这是第一种定位战略,以推导体为指南。 背后的原因同样是,XPath需要很多维修,因为标记很容易改变。 此外,XPath语是最缓慢和非常难以解冻的。

Always prefer protractor-specific locators such as by.model and by.binding

特定轨道定位器,例如: 模式和内容。 具有约束力的是短、具体和易于阅读的。 在他们的帮助下,也非常容易写我们的位置。

Example

<ul class = "red">
   <p>{{color.name}}</p>
   <p>{{color.shade}}</p>
   <p>{{color.code}}</p>
</ul>

<span class = "details">
   <span class = "personal">
      <input ng-model = "person.name">
   </span>
</span>

关于上述法典,建议避免下列内容:

var nameElement = element.all(by.css( .red p )).get(0);
var personName = element(by.css( .details .personal input ));

另一方面,建议使用以下手段:

var nameElement = element.all(by.css( .red p )).get(0);
var personName = element(by.css( .details .personal input ));

var nameElement = element(by.binding( color.name ));
var personName = element(by.model( person.name ));

如果没有医生的定位器,则建议由他人选择。

Always avoid text locators for frequently changing text

我们必须避免以文字为基础的定位器,例如由Text、ButtonText和csContaning 。 案文是因为纽芬兰文、链接和标签的案文经常随着时间的推移而变化。

Page Objects

前面已经讨论过,页面物体概括了有关我们申请网页内容的信息,因为这有助于我们撰写更清洁的测试案例。 页面物体的一个非常有用的优势是,可在多种测试中重新使用,如果我们的申请模板发生变化,我们只需要更新页标。 下面是一些关于必须使用探测器进行检测的页面物体的建议:

To interact with page under test, use page objects

建议使用页面物体与正在测试的网页互动,因为它们能够概括有关正在测试的网页内容的信息,并且可以再使用。

Always declare one-page object per file

我们应该在自己的档案中确定每一页的物体,因为它保持了该代码的清洁,发现事情变得容易。

At the end of page object file always uses a single module.exports

建议每一页标均应宣布单一类别,以便我们只需要出口一个类别。 例如,应当避免下列用途:

var UserProfilePage = function() {};
var UserSettingsPage = function() {};
module.exports = UserPropertiesPage;
module.exports = UserSettingsPage;

但另一方面,建议使用以下手段:

/** @constructor */
var UserPropertiesPage = function() {};

module.exports = UserPropertiesPage;

Declare all the required modules at the top

我们应该宣布所有必要的模块都放在网页标的顶端,因为它使模块能够清楚和容易找到。

Instantiate all page objects at the beginning of the test suite

建议在测试程序开始时对所有页面物体进行即时处理,因为这将与测试法分开,并且使该套物的所有规格都具备附属条件。

Do not use expect() in page objects

我们不应将期望()放在一页的物体上,即我们不应在我们的页面物体上提出任何主张,因为所有说法都必须在试验案例中作出。

另一个原因是,测试的读者应当能够理解申请的行为,只读测试案例。