Introdução aos testes de cliente com Ember

Meu objetivo é criar um diálogo sobre os paradigmas de teste do cliente com Ember.js

O estilo de teste de unidade do Ember é um pouco um retrocesso para mim pessoalmente. Trabalhei no laboratório de pesquisa de engenharia de software como aluno de graduação na universidade e tive a sorte de ter um professor apresentando o conceito para mim muito antes de ele entrar em qualquer currículo formal. Minha própria tenacidade é responsável pelo aprendizado real.

No teste, um dos objetivos principais é avaliar a exatidão de um trecho de código, camada de código, subsistema ou, com menos frequência, de todo o sistema.

Primeiro, algum vocabulário que parece estar em uso na comunidade, a seguir falarei sobre os assistentes de teste do Ember e, finalmente, mencionarei o teste assíncrono QUnit.

Vocabulário usado

Vou ordená-los do complexo ao simples.

Teste de aceitação:
Este é um teste abrangente cliente => servidor => cliente que envolve a invocação de ‘end-points’ da API, bem como o uso mínimo de simulação

Teste de Integração:
Este é um teste abrangente cliente => mock_server => cliente que envolve o exercício do código do cliente com uma implementação simulada da interface que se espera do serviço. Ele pode ser totalmente funcional ou simular partes do cliente para concentrar o teste em um subsistema específico.

Teste de Unidade:
Este é um termo genérico para verificar se as expectativas de um determinado método ou função estão operando corretamente. Também ouvi esse termo ser usado para descrever um conjunto de testes sobre um objeto específico.

O objetivo do teste é validar a exatidão do sistema ou uma subunidade do sistema. Se você puder verificar as subunidades individuais e o funcionamento correto, por meio de coleta e cobertura, poderá aumentar a confiança de que todo o sistema está funcionando.

Ember usa QUnit para teste. Isso está no estilo de asserção / expectativa da unidade de teste tradicional – e é sintaticamente diferente do teste orientado por comportamento – que é efetivamente o mesmo apenas organizado mais sobre a expectativa de comportamento do que simplesmente correção de dados.

Ember Integration Test Helpers

O Ember-Test fornece ao desenvolvedor uma variedade de ajudantes para fins de teste de integração
http://emberjs.com/api/classes/Ember.Test.html

click

currentPath


currentRouteName


currentURL


fillIn


find

Eles não são necessários para o teste de unidade típico de objetos – que deve ser considerado como a primeira e mais útil ferramenta – especialmente ao construir uma biblioteca.

Se você pensar no software como uma árvore de nós e arestas, onde cada nó é a sua árvore, o teste de unidade eficaz é testar o nó e simular as arestas. Para simplificar, às vezes pode ser eficaz testar um grupo de objetos em conjunto – isso é um sinal de acoplamento – muito acoplamento e você terá um programa de televisão britânico – e uma dor de cabeça quando você tentar reutilizar um objeto independentemente .

Testes Assíncronos

O QUnit tem sido usado por muito tempo para teste de javascript assíncrono – no Ember-Testing, esses métodos são configurados para retornar uma promessa – você pode usar ‘then’ para lidar com qualquer comportamento assíncrono.

Exemplo (coffeescript):

test "default template", ->
visit
("/").then ->
ok exists
("*"), "Found Some HTML"

Neste exemplo, ‘ok’ é uma função auxiliar de asserção QUNIT – a lista completa está aqui

http://api.qunitjs.com/category/assert/

** Palavras Finais **

O Teste de Unidade é uma forma de manter a correção de um sistema, melhorar a velocidade de desenvolvimento, gerenciar a estrutura de um sistema e também tem um ótimo sabor no brinde.

Os testes são feitos para mudar, eles podem ser excluídos, reescritos, um teste que é frágil é melhor excluído, os testes devem se adaptar e mudar e ser removidos – sem eles – qualquer sistema – até mesmo um sistema simples começará a se degradar – eu vi isso acontece em questão de 2 semanas.

O software sem testes de unidade automatizados é como um carro de aço sem proteção contra ferrugem.

Não há substituto para o teste de software. O teste de software é parte de uma disciplina abrangente para estabelecer qualidade e repetibilidade. Tenho aprendido sobre testes nos últimos 10 anos e ainda estou aprendendo.

O que eu sei profundamente, por meio de repetidas experiências – é que com o uso de testes seu software irá melhorar e sua qualidade de trabalho irá melhorar. O teste de software, apesar de qualquer dificuldade, paga os dividendos.

Obrigado.

** Errata **