Melhores práticas sobre como incluir testes unitários em uma biblioteca

Question

Estou trabalhando em uma biblioteca de código geral para ActionScript 3.0 chamada as3lib que inclui várias extensões para a API principal e algumas funções úteis.Escrevi vários testes unitários (usando FlexUnit) para ter certeza de que tudo está funcionando corretamente.

Qual a melhor forma de organizar esses testes na biblioteca? Atualmente, tenho todo o meu código em src/ e meus testes em test/ mas configurei um projeto Flex secundário para executar os testes de unidade.Também estou adicionando e removendo manualmente os arquivos de teste da biblioteca quando desejo executar os testes.

O que estou fazendo não parece certo.Existe uma maneira melhor?De preferência aquele em que a biblioteca compilada não inclua os arquivos de teste, mas não preciso de dois projetos separados para testá-los.

Answer 1

A maneira como fizemos essas coisas na minha empresa é que realmente incluímos o diretório de origem e, em seguida, temos dois arquivos MXML do Application que usamos. Um é o conjunto de testes, que inclui todos os links apropriados para as classes de teste de unidade, o outro é o principal aplicativo. Também temos duas estruturas de pacotes dentro da pasta SRC: uma estrutura de pacote com .. e outro test.com ... verifique se isso TUDO O código -fonte para testes de unidade são SEMPRE No pacote de testes-dessa maneira, você pode usar apenas um SVN ignorar e também pode garantir que seus testes não criem relacionamentos dependentes e codificados com outros projetos.

Existem duas maneiras que usamos para garantir que os arquivos de origem do Test.com não estejam incluídos. O sistema de construção automatizado apenas faz referência ao aplicativo principal e, como isso importa apenas do com., Mxmlc.exe incluirá apenas os arquivos para o aplicativo principal. Ao construir localmente, dentro do Eclipse, você pode controlar como as coisas se formam clicando na pequena seta ao lado de depurar e rolar para "organizar os favoritos". Ao clicar em "Adicionar", você poderá selecionar todos os arquivos .mxml de nível raiz que fazem referência à classe Application. Certifique -se de adicionar o aplicativo base e o novo arquivo de aplicação de teste de unidade. Quando você clica em "OK", a seta agora permite depurar como o aplicativo principal ou sua estrutura de teste de unidade.

Como um aparte, também usamos o Flexunit como nossa estrutura de teste. Eu gosto disso.

Answer 2

Eu fiz isso semelhante à maneira como você está descrevendo no passado, mas parece o tipo de coisa de onde Springas Pode ser bastante útil para adicionar e removê -los dinamicamente da configuração. Você já tentou investigar isso?

Answer 3

Temos diretórios de SRC e testes separados no nível superior em nossas bibliotecas. Nossos aplicativos são embalagens muito finas em torno de projetos de bibliotecas, para que não precisem de testes. Também temos um projeto de aplicativo FlexUnit, para executar os testes do FlexBuilder.

Usamos o MAVEN para o nosso sistema principal de construção, e o plug-in do Sonatype Flex executa todos os nossos testes de unidade durante a compilação, mesmo em nosso servidor contínuo baseado em Linux. O Maven padroniza a procura de testes em um diretório 'testes', que foi uma boa justificativa para escolher esse local.

Answer 4

Vou contra o fluxo aqui e sugiro a criação de um projeto totalmente diferente para seus testes.Acredito que geralmente não importa onde você coloca os testes, desde que seja consistente e gerenciável.No entanto, para mim existem três razões convincentes para ter um projeto separado para os testes:

1. Separação de preocupações.Primeiro, sua biblioteca tem um propósito, os testes têm outro.Embora os testes precisem da biblioteca para funcionar, a biblioteca não tem uso real para os testes. Observação que não estou dizendo que os testes são inúteis, longe disso.Os testes existem para verificar a integridade da biblioteca, mas em um ambiente de produção os testes não servem para nada.

2. Menos inchaço e arquivos menores.Os testes nem sempre são triviais.Mas mesmo que todos estivessem, ainda estariam usando espaço em disco.Como os testes não são usados ​​em um ambiente de produção, isso é inútil.Além disso, separar os testes em um novo projeto torna a estrutura do arquivo muito mais limpa.

3. Os ambientes de CI geralmente são mais limpos de configurar quando os testes não estão disponíveis.

Embora seja certamente possível resolver pelo menos o segundo problema com as diretivas do compilador, é um trabalho desnecessário quando é muito mais fácil simplesmente separar os dois.Testar uma biblioteca ou aplicativo que pode exigir que você use o mesmo namespace (qualquer classe interna?) Também não é um problema, pois seu projeto de testes pode espelhar os namespaces.Obviamente, isso torna necessário não haver colisões de nomes nos namespaces, mas isso é trivial.

Em termos de suporte ao Flash Builder, é ótimo separar as coisas em dois projetos.Tudo o que você precisa fazer para criar um novo teste é clicar com o botão direito na classe que deseja testar, pedir para criar um novo teste e escolher seu projeto de testes em vez do atual na caixa de diálogo que aparece.Essa é realmente a principal razão pela qual eu e os membros da minha equipe tivemos dificuldade em justificar a escrita de testes quando entramos no TDD, pois havia muita sobrecarga apenas para começar.Com o estado atual do IDE, é ridiculamente simples e útil.

No entanto, como acontece com qualquer técnica, existem ressalvas.Por um lado, não é óbvio que os testes estejam em um projeto diferente, a menos que seja documentado.Ter os testes no mesmo projeto resolve esse problema de maneira eficaz.Por outro lado, isso é facilmente resolvido configurando o maven ou outras ferramentas de gerenciamento de dependências que você possa ter em seu ambiente.Outro problema é que se você tiver uma estrutura de pacote em seu projeto de testes que espelhe aquela da biblioteca ou aplicativo, haverá alguma sobrecarga de manutenção na sincronização dessas estruturas.Embora não seja um grande problema e seja facilmente resolvido com scripts, ainda vale a pena mencioná-lo.

De qualquer forma, é assim que eu faço.