Pergunta

G'day,

Eu estou trabalhando com um grupo de desenvolvedores no exterior que têm vindo a utilizar o termo unidade testar muito vagamente.

As conversações de documentos QA cerca de escrever testes de unidade e, em seguida, realizar a unidade de teste do sistema.

Esta não se alinha com a minha interpretação do que o teste de unidade é em tudo.

Estou habituado a testes de unidade sendo um teste ou conjunto de testes que estão sendo usados ??para exercer uma única classe, geralmente como uma caixa preta. A classe sob teste pode exigir outras classes para ser incluída pela aplicação, mas geralmente é uma classe única que está a ser exercida por meio do teste (s) unidade.

Então você tem o teste do sistema funcionais, testes intergration, teste de aceitação, etc.

Eu quero saber este é um pedante pouco da minha parte? Ou isso é o que você pensa quando se refere a testes unitários e testes de unidade?

Edit: Rob Wells. Eu preciso esclarecer que aproxima tais testes a partir de uma perspectiva caixa preta é apenas um aspecto. Ao usar objetos fictícios para verificar comportamentos internos, você realmente está testando a partir de uma perspectiva caixa branca, porque você sabe o que você quer que aconteça dentro da caixa.

Foi útil?

Solução

Eu tento implementar testes de unidade para teste de apenas um único método. e eu fazer um esforço para Creta classes "simulados" para classes dependentes e métodos utilizados pelo método estou testando ... ... para que o exercício do código em que o método não faz no código de chamada fato, em outros métodos de teste de unidade não é suposto ser "Testing" (Há outros testes de unidade para esses métodos) Desta forma, uma falha do teste de unidade indica de forma confiável uma falha do método do teste de unidade está testando ...

aulas Mock são projetados para "simular" a interface e comportamento das classes dependentes de modo que o método que eu estou testando pode chamá-los e eles vão se comportar padrão ina, maneira bem definida de acordo com os requisitos do sistema. A fim de fazer este trabalho abordagem, as chamadas para essas classes dependentes e aos seus métodos devem ser feitas em uma interface bem definida, de modo que o processo de "testador" pode "injetar" a versão Mock de teh classe dependente para a classe que está sendo testado em vez da versão de produção real .... Este é um bocado como um padrão de design comum referido como "injeção de dependência", ou "Inversão de Controle" (COI)

Existem várias ferramentas de terceiros no mercado para ajudá-lo a implementar este tipo de padrão. Uma Tenho ouvido falar de é chamado de "Rhino-Mock" ou algo parecido ...

Edit: Rob Wells. @Charles. Obrigado por isso. Eu tinha esquecido usando objetos mock para substituir completamente usando outras classes exceto para aquele sob teste.

Um par de outras coisas que eu lembrado depois de mencionar objetos mock é que:

  • que pode ser usado para erros simular estar devolvidos pelas classes incluídos.
  • que pode ser usado para exceções aumento específicas para verificar o tratamento de exceção na classe sob teste.
  • que pode ser usado para itens de simulador onde os custos de instalação são elevados, por exemplo, um grande back-end SQL DB.
  • eles podem ser usados ??para verificar o conteúdo de uma solicitação de entrada.

Para mais informações, dê uma olhada no artigo de Martin Fowler chamado de " Mocks Não são Stubs " e o artigo do Pragmatic Programmers " Mock Objects "

Outras dicas

Os testes unitários são geralmente usados ??por desenvolvedores para testar seções isoladas de código. Eles cobrem casos de fronteira, casos de erro e casos normais. Eles destinam-se a demonstrar a exactidão de um segmento limitado de código. Se todos os testes de unidade passar, então você tem demonstrado que os seus segmentos isolados de código de fazer o que é suposto fazer.

Quando você faz testes de integração, você está olhando para casos end-to-end, para ver se todos os segmentos que passaram de trabalho teste de unidade em conjunto. verificações de testes funcionais para ver se o código atende aos requisitos especificados. O teste de aceitação é feito por usuários finais para ver se eles aprovam o produto final.

Não há razão para que testes de unidade não pode se estender por várias classes, ou mesmo sub-módulos, enquanto o teste está tratando apenas uma operação de negócio consistente. Pense em "calculateWage", um método de um BO que utiliza estratégias diferentes para calcular o salário de uma pessoa. Isso é teste de uma unidade na minha opinião.

Já ouvi falar de técnicas em que muitos dos testes de unidade são feitas em primeiro lugar, e desenvolvimento é feito em torno deles. Alguém acaba comentou dizendo que este é "Test Driven Development." - TDD (Graças Elie)

Mas se esta é uma operação no mar que é, possivelmente, vai cobrar-lhe mais dinheiro, porque eles estão gastando tempo fazendo esses testes de unidade - então eu teria cuidado. Obter uma segunda opinião de alguém, experiência com testes de unidade que irá verificar se eles estão realmente fazendo como eles dizem.

No meu entendimento, o teste de unidade irá adicionar um pouco mais de tempo para qualquer projeto de desenvolvimento, mas é claro que pode oferecer algum controle de qualidade. No entanto, este é o tipo de controle de qualidade que eu iria querer com uma no projeto da casa. Isso pode ser apenas algo que a empresa offshore joga fora lá para lhe dar uma calorosa difusa.

Há uma diferença entre o processo usado para teste e a tecnologia que é usada para apoiá-lo. As várias estruturas utilizadas para testes de unidade são geralmente muito flexível e pode ser usado para testar pequenas unidades de código, unidades grandes e mesmo testando processos inteiros. Essa flexibilidade pode levar a confusão.

A minha recomendação é que qualquer que seja a metodologia específica ou processar você adotar que você segregar os vários teste de unidade em conjuntos distintos ou módulos. O arranjo exato depende do seu código e organização da sua empresa.

O efeito acumulativo de usar o framework de teste de unidade é que grande parte dos testes do código é automatizado. Adotadas desenvolvedores corretamente pode avaliar mudanças no código código melhor com a passar por um processo de Q & A completa. Quanto ao processo de Q & A em si não faz o seu tempo mais produtivo como a qualidade do código que sai do desenvolvimento deve ser maior.

Entenda que não é a resposta para todos os problemas de qualidade apenas uma ferramenta útil como os outros que você usa.

Wikipedia parece sugerir que o teste de unidade é de cerca de testar a menor quantidade de código que seria um método em uma classe, no caso de programação OO.

Alguns podem ter um termo mais geral do que eles querem dizer com testes de unidade, onde alguns podem pensar de alguns testes de integração como sendo testes de unidade onde a unidade é uma mistura de componentes.

há uma visão tradicional do http://en.wikipedia.org/wiki/Software_testing como parte do http://en.wikipedia.org/wiki/Software_engineering . mas eu gosto da idéia de um teste de unidade ágil:. um teste é um teste de unidade ágil se é rápido o suficiente para que os programadores sempre executá-lo

Um teste de unidade é a parte menor e só de confiança que você pode obter-se no seu caminho para ser feito. Isso é o que importa, de forma iterativa a construção de um escudo contra a regressão e desvio spec, não como você realmente integrá-lo à sua arquitetura orientada a objetos.

Esta é quase uma repetição do " O que é uma 'Unidade'? " questão .

"Unidade" pode ser definido de forma flexível. Se o seu documento não tiver uma definição de "unidade", você vai precisar para esclarecer isso.

Pode ser que eles pensam de unidade como uma grande montagem de código. Que não é a definição mais desejável.

Embora concorde que você tem várias camadas de testes (unidade, módulo, pacote, aplicação), eu também acho que muito disso pode ser feito com ferramentas de testes de unidade. Levando a "o que é uma unidade?" perguntas chegando o tempo todo.

Unidade depende do contexto. Para um desenvolvedor individual, unidade devem ser da classe. Às vezes, ele vai módulo também média ou pacote.

Para uma equipe, no entanto, sua unidade pode ser um pacote ou um aplicativo completo.

O que importa o que pensamos? A questão aqui é a sua infelicidade com os termos que eles usam no documento. Por que você não discutir com eles?

anos Dez atrás, antes do uso atual do "teste de unidade", como provas escritas em código, a mesma designação foi aplicada a testes manuais. Eu trabalhei para uma empresa de desenvolvimento de software com um processo de desenvolvimento de software muito formalizada. Tivemos que escrever "testes de unidade" antes de escrever qualquer código. Naquela época, os testes de unidade foram escritos em um documento de texto (tal como no Word). Eles descreveram as etapas exatas que o usuário estava a seguir usando o aplicativo. Por exemplo, eles descreveram a entrada exata de tipo na página para configurar um novo cliente. Ou, o usuário foi para procurar um determinado produto, e ver que a informação apresentada correspondeu ao documento de teste. Assim, o teste foi um script que o testador seguido, onde também gravou os resultados. Quando a nova encarnação de teste de unidade veio, foi confuso por um tempo tentando descobrir se eles significava que os velhos, os testes humanos ou os novos testes, codificados.

I liderar um grupo de equipe offshore também. Supposely temos um conjunto de testes de unidade ... mas isso não significa muito. :) Então nós confiamos muito mais sobre o funcional e testadores para a qualidade. O problema herdar com o teste de unidade é que você tem perfeito conhecimento dos funcionais, e você confia os desenvolvedores. No mundo real, que é difícil de assumir ..

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top