Transferidor - Guia de estilo para transferidor

Neste capítulo, vamos aprender em detalhes sobre o guia de estilo para transferidor.

Introdução

O guia de estilo foi criado por dois engenheiros de software chamados, Carmen Popoviciu, engenheiro de front-end no ING e Andres Dominguez, engenheiro de software do Google. Portanto, este guia de estilo também é chamado de Carmen Popoviciu e guia de estilo do Google para transferidor.

Este guia de estilo pode ser dividido nos seguintes cinco pontos-chave -

Regras genéricas
Estrutura do Projeto
Estratégias de localizador
Objetos de Página
Suítes de teste

Regras Genéricas

A seguir estão algumas regras genéricas que devem ser tomadas cuidado ao usar o transferidor para teste -

Não teste de ponta a ponta o que já foi testado na unidade

Esta é a primeira regra genérica dada por Carmen e Andres. Eles sugeriram que não devemos realizar o teste e2e no código que já foi testado na unidade. A principal razão por trás disso é que os testes de unidade são muito mais rápidos do que os testes e2e. Outra razão é que devemos evitar testes duplicados (não execute testes unitários e e2e) para economizar nosso tempo.

Use apenas um arquivo de configuração

Outro ponto importante recomendado é que devemos usar apenas um arquivo de configuração. Não crie um arquivo de configuração para cada ambiente que você está testando. Você pode usargrunt-protractor-coverage a fim de configurar diferentes ambientes.

Evite usar lógica em seu teste

Devemos evitar o uso de instruções IF ou loops FOR em nossos casos de teste porque, se fizermos isso, o teste pode passar sem testar nada ou pode ser executado muito lentamente.

Faça o teste independente no nível do arquivo

O transferidor pode executar o teste paralelamente quando o compartilhamento está ativado. Esses arquivos são então executados em diferentes navegadores conforme e quando estiverem disponíveis. Carmen e Andres recomendaram tornar o teste independente pelo menos no nível do arquivo porque a ordem em que eles serão executados pelo transferidor é incerta e, além disso, é bastante fácil executar um teste isoladamente.

Estrutura do Projeto

Outro ponto importante em relação ao guia de estilo do Transferidor é a estrutura do seu projeto. A seguir está a recomendação sobre a estrutura do projeto -

Teste e2e tateando em uma estrutura sensível

Carmen e Andres recomendaram que devemos agrupar nossos testes e2e em uma estrutura que faça sentido para a estrutura do seu projeto. O motivo dessa recomendação é que a localização dos arquivos se tornaria fácil e a estrutura da pasta seria mais legível. Esta etapa também separará os testes e2e dos testes de unidade. Eles recomendaram que o seguinte tipo de estrutura deve ser evitado -

|-- 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

Por outro lado, eles recomendaram o seguinte tipo de estrutura -

|-- 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

Estratégias de localizador

A seguir estão algumas estratégias de localizador que devem ser tomadas com cuidado ao usar o transferidor para teste -

Nunca use XPATH

Esta é a primeira estratégia de localizador recomendada no guia de estilo do transferidor. As razões por trás disso são que o XPath requer muita manutenção porque a marcação está facilmente sujeita a alterações. Além disso, as expressões XPath são as mais lentas e muito difíceis de depurar.

Sempre prefira localizadores específicos do transferidor, como by.model e by.binding

Os localizadores específicos do transferidor, como by.model e by.binding, são curtos, específicos e fáceis de ler. Com a ajuda deles, é muito fácil escrever também nosso localizador.

Exemplo

View

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

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

Para o código acima, é recomendado evitar o seguinte -

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

Por outro lado, recomenda-se o uso do seguinte -

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

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

Quando nenhum localizador de transferidor estiver disponível, é recomendável preferir by.id e by.css.

Sempre evite localizadores de texto para texto alterado com frequência

Devemos evitar localizadores baseados em texto, como by.linkText, by.buttonText e by.cssContaningText porque o texto dos botões, links e rótulos mudam frequentemente com o tempo.

Objetos de Página

Conforme discutido anteriormente, os objetos de página encapsulam informações sobre os elementos em nossa página de aplicativo e, devido a isso, nos ajudam a escrever casos de teste mais limpos. Uma vantagem muito útil dos objetos de página é que eles podem ser reutilizados em vários testes e, caso o modelo de nosso aplicativo tenha sido alterado, só precisamos atualizar o objeto de página. A seguir estão algumas recomendações para objetos de página que devem ser tomados com cuidado ao usar o transferidor para teste -

Para interagir com a página em teste, use objetos de página

É recomendável usar objetos de página para interagir com a página em teste porque eles podem encapsular informações sobre o elemento na página em teste e também podem ser reutilizados.

Sempre declare o objeto de uma página por arquivo

Devemos definir cada objeto de página em seu próprio arquivo porque ele mantém o código limpo e fica fácil encontrar as coisas.

No final da página, o arquivo de objeto sempre usa um único módulo.

Recomenda-se que cada objeto de página declare uma única classe, de modo que só precisemos exportar uma classe. Por exemplo, o seguinte uso de arquivo objeto deve ser evitado -

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

Mas, por outro lado, é recomendado o uso a seguir -

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

module.exports = UserPropertiesPage;

Declare todos os módulos necessários no topo

Devemos declarar todos os módulos necessários na parte superior do objeto da página porque isso torna as dependências do módulo claras e fáceis de encontrar.

Instancie todos os objetos de página no início do conjunto de testes

Recomenda-se instanciar todos os objetos de página no início do conjunto de testes porque isso separará as dependências do código de teste e também tornará as dependências disponíveis para todas as especificações do conjunto.

Não use expect () em objetos de página

Não devemos usar expect () em objetos de página, ou seja, não devemos fazer nenhuma asserção em nossos objetos de página porque todas as asserções devem ser feitas em casos de teste.

Outra razão é que o leitor do teste deve ser capaz de entender o comportamento do aplicativo lendo apenas os casos de teste.

↰ Previous page