Python - doctest vs. unittest [fechado]

Estou tentando começar o teste de unidade em Python e queria saber se alguém poderia explicar as vantagens e desvantagens de doctest e unittest.

Para quais condições você usaria cada um?

Ambos são valiosos. Eu uso o doctest e o nariz substituindo o unittest. Uso doctest para casos em que o teste está dando um exemplo de uso que é realmente útil como documentação. Geralmente, eu não faço esses testes abrangentes, visando apenas informativos. Estou efetivamente usando o doctest ao contrário: não para testar meu código está correto com base no meu doctest, mas para verificar se minha documentação está correta com base no código.

O motivo é que acho que os testes abrangentes sobrecarregam demais a sua documentação; portanto, você acabará com as doutrinas inutilizáveis ​​ou os testes incompletos.

Na verdade, para testar o código , o objetivo é testar minuciosamente todos os casos, em vez de ilustrar o que é feito pelo exemplo, que é um objetivo diferente que eu acho que é melhor alcançado por outras estruturas.

Eu uso unittest quase exclusivamente.

De vez em quando, coloco algumas coisas em uma doutrina que pode ser usada pelo doctest.

95% dos casos de teste são unittest.

Por quê? Eu gosto de manter as doutrinas um pouco mais curtas e mais objetivas. Às vezes, os casos de teste ajudam a esclarecer uma sequência de documentos. Na maioria das vezes, os casos de teste do aplicativo são muito longos para uma sequência de documentos.

Outra vantagem do teste de documentos é que você garante que seu código faça o que a documentação diz. Depois de um tempo, as alterações de software podem fazer com que sua documentação e código façam coisas diferentes. :-)

Eu trabalho como bioinformática e a maior parte do código que escrevo são scripts "uma vez, uma tarefa", código que será executado apenas uma ou duas vezes e que executa uma única tarefa específica.

Nessa situação, escrever grandes unittests pode ser um exagero, e os doctests são um compromisso útil. Eles são mais rápidos de escrever e, como geralmente são incorporados ao código, permitem sempre ficar de olho em como o código deve se comportar, sem precisar abrir outro arquivo. Isso é útil ao escrever pequenos scripts.

Além disso, os testes de documentos são úteis quando você precisa passar seu script para um pesquisador que não seja especialista em programação. Algumas pessoas acham muito difícil entender como os unittests são estruturados; por outro lado, os doctests são exemplos simples de uso, para que as pessoas possam copiá-los e colá-los para ver como usá-los.

Portanto, para resumir minha resposta: os doctests são úteis quando você precisa escrever pequenos scripts e quando precisa passá-los ou mostrá-los a pesquisadores que não são cientistas da computação.

Se você está apenas começando com a idéia de teste de unidade, eu começaria doctestporque é muito simples de usar. Naturalmente, também fornece algum nível de documentação. E para testes mais abrangentes doctest, você pode colocar os testes em um arquivo externo para que não sobrecarregue sua documentação.

Eu sugeriria unittestse você tem experiência em usar o JUnit ou algo similar, onde deseja poder escrever testes de unidade geralmente da mesma maneira que em outros lugares.

Eu uso unittest exclusivamente; Eu acho que o doctest confunde demais o módulo principal. Provavelmente isso tem a ver com a escrita de testes completos.

Usar os dois é uma opção válida e bastante simples. O doctestmódulo fornece os métodos DoctTestSuitee DocFileSuiteque criam um conjunto de testes compatível com unittest a partir de um módulo ou arquivo, respectivamente.

Então, eu uso os dois e normalmente uso o doctest para testes simples com funções que requerem pouca ou nenhuma configuração (tipos simples de argumentos). Na verdade, acho que alguns testes doctest ajudam a documentar a função, em vez de diminuí-la.

Mas, para casos mais complicados e para um conjunto mais abrangente de casos de teste, eu uso o unittest, que fornece mais controle e flexibilidade.

Não uso o doctest como substituto do unittest. Embora se sobreponham um pouco, os dois módulos não têm a mesma função:

• Eu uso unittestcomo uma estrutura de teste de unidade, o que significa que me ajuda a determinar rapidamente o impacto de qualquer modificação no restante do código.

• Uso doctestcomo garantia que os comentários (ou seja, docstrings) ainda são relevantes para a versão atual do código.

Os benefícios amplamente documentados do desenvolvimento orientado a testes que recebo unittest . doctestresolve o risco muito mais sutil de comentários desatualizados, enganando a manutenção do código.

Eu quase nunca uso documentos. Quero que meu código seja auto-documentado, e os documentos fornecem a documentação para o usuário. A IMO, ao adicionar centenas de linhas de testes a um módulo, torna os documentos muito menos legíveis. Também acho os testes de unidade mais fáceis de modificar quando necessário.

Doctestalgumas vezes pode levar a resultados errados. Especialmente quando a saída contém seqüências de escape. Por exemplo

def convert():
    """
    >>> convert()
    '\xe0\xa4\x95'
    """
    a = '\xe0\xa4\x95'
    return a
import doctest
doctest.testmod()

dá

**********************************************************************
File "hindi.py", line 3, in __main__.convert
Failed example:
    convert()
Expected:
    'क'
Got:
    '\xe0\xa4\x95'
**********************************************************************
1 items had failures:
   1 of   1 in __main__.convert
***Test Failed*** 1 failures. 

Também não verifica o tipo de saída. Ele apenas compara as seqüências de saída. Por exemplo, ele tornou racional algum tipo, que imprime como um número inteiro se for um número inteiro. Então suponha que você tenha uma função que retorne racional. Portanto, um doctest não se diferencia se a saída for um número inteiro racional ou um número inteiro.

Eu prefiro os sistemas baseados em descoberta ("nariz" e "py.test", usando o primeiro atualmente).

O doctest é bom quando o teste também é bom como documentação, caso contrário, eles tendem a sobrecarregar demais o código.