Desenvolvimento de interface do usuário em JavaScript usando os princípios do TDD

Eu tive muitos problemas tentando encontrar a melhor maneira de seguir adequadamente os princípios do TDD enquanto desenvolvia a interface do usuário em JavaScript. Qual é a melhor maneira de fazer isso?

É melhor separar o visual do funcional? Você desenvolve os elementos visuais primeiro, depois escreve testes e depois codifica para funcionalidade?

0
adicionado editado
Visualizações: 9

7 Respostas

0
adicionado

Eu achei a arquitetura MVP muito adequada para escrever UIs testáveis. Suas classes Apresentador e Modelo podem ser simplesmente testadas em 100%. Você só precisa se preocupar com o View (que deve ser apenas uma camada estúpida e fina que dispara eventos para o apresentador) para testes de interface do usuário (com selênio, etc.)

Note que no estou falando sobre o uso de MVP inteiramente no contexto da interface do usuário, sem necessariamente cruzar para o lado do servidor. Sua interface do usuário pode ter seu próprio apresentador e modelo que vive inteiramente no lado do cliente. O apresentador orienta a lógica de interação/validação da interface do usuário, etc., enquanto o modelo mantém as informações de estado e fornece um portal para o back-end (onde você pode ter um modelo separado).

Você também deve dar uma olhada na técnica de TDD do Apresentador Primeiro .

0
adicionado

O que eu faço é cutucar o Dom para ver se estou conseguindo o que espero. Um grande efeito colateral disso é que, ao tornar seus testes mais rápidos, você também torna seu aplicativo mais rápido.

Acabei de lançar um kit de ferramentas de código aberto que ajudará imensamente com JavaScript tdd. É uma composição de muitas ferramentas de software livre que oferece a você um aplicativo de backbone requirejs funcional pronto para uso.

Ele fornece comandos únicos para executar: servidor web dev, gerenciador de testes jasmine single browser, gerenciador de testes jasmine js-test-driver multi browser e concatenization/minification para JavaScript e CSS. Ele também gera uma versão não minificada do seu aplicativo para depuração de produção, pré-compila seus modelos de guidão e oferece suporte à internacionalização.

Nenhuma configuração é necessária. Apenas funciona.

http://github.com/davidjnelson/agilejs

0
adicionado

Estou prestes a começar a fazer o Javascript TDD em um novo projeto em que estou trabalhando. Meu plano atual é usar qunit para fazer o teste da unidade. Enquanto o desenvolvimento dos testes pode ser executado simplesmente atualizando a página de teste em um navegador.

Para integração contínua (e garantir que os testes sejam executados em todos os navegadores), vou usar o Selenium para carregar automaticamente o teste aproveitar em cada navegador, e leia o resultado. Esses testes serão executados em cada check-in para o controle de origem.

Também vou usar o JSCoverage para obter uma análise de cobertura de código dos testes. Isso também será automatizado com o Selenium.

Eu estou atualmente no meio de configurar isso. Eu atualizarei esta resposta com detalhes mais precisos uma vez que eu tenha a configuração elaborada.


Ferramentas de teste:

0
adicionado

Esta é a principal razão pela qual mudei para o Google Web Toolkit ... Eu desenvolvo e testei em Java e tenho uma expectativa razoável de que o JavaScript compilado funcionará corretamente em uma variedade de navegadores. Como o TDD é basicamente uma função de teste de unidade, a maior parte do projeto pode ser desenvolvida e testada antes da compilação e da implantação.

Os conjuntos de testes de Integração e Funcionais verificam se o código resultante está funcionando como esperado depois de implementado em um servidor de teste.

0
adicionado

Eu nunca tive sucesso com o código da interface do usuário do TDD. O mais próximo que chegamos foi, na verdade, separar o código da interface do usuário tanto quanto possível da lógica do aplicativo. Esta é uma razão pela qual o padrão de controlador de visão de modelo é útil - o modelo e o controlador podem ser TDD sem muitos problemas e sem ficar muito complicado.

Na minha experiência, a visão sempre foi deixada para nossos testes de aceitação do usuário (nós escrevemos aplicativos web e nossos UATs usavam o HttpUnit do Java). No entanto, neste nível, é realmente um teste de integração, sem a propriedade de teste em isolamento que desejamos com o TDD. Devido a essa configuração, tivemos que escrever primeiro nossos testes/códigos de controle/modelo, depois a interface do usuário e o UAT correspondente. No entanto, no código GUI Swing que tenho escrito ultimamente, tenho escrito o código da GUI primeiro com stubs para explorar meu design do front end, antes de adicionar ao controller/model/API. YMMV aqui embora.

Então, para reiterar, o único conselho que posso dar é o que você já parece suspeitar - separe seu código de interface com a sua lógica tanto quanto possível e TDD.

0
adicionado

Eu já fiz algum TDD com Javascript no passado, e o que eu tive que fazer foi fazer a distinção entre os testes Unit e Integration. O Selenium irá testar o seu site global, com a saída do servidor, seus posts, chamadas de ajax, tudo isso. Mas para testes unitários, nada disso é importante.

O que você quer é apenas a interface do usuário com a qual você vai interagir e seu script. A ferramenta que você usará para isso é basicamente JsUnit , que recebe um documento HTML, com algumas funções Javascript na página e os executa no contexto da página. Então, o que você vai fazer é incluir o HTML fragmentado na página com suas funções. A partir daí, você pode testar a interação do seu script com os componentes da interface do usuário na unidade isolada do HTML, seu script e seus testes.

Isso pode ser um pouco confuso, então vamos ver se podemos fazer um pequeno teste. Deixa para algum TDD assumir que depois que um componente é carregado, uma lista de elementos é colorida com base no conteúdo do LI.

tests.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    
  • red
  • green
   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

Obviamente, o TDD é um processo de várias etapas, portanto, para nosso controle, precisaremos de vários exemplos.

yourcontrol.js (passo1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (passo 2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

Você provavelmente pode ver o ponto problemático aqui, você tem que manter o seu mock HTML aqui na página em sincronia com a estrutura do que o seu servidor controla. Mas você consegue um bom sistema para o TDD com JavaScript.

0
adicionado