O que é o teste de unidade?

votos
193

Eu vi muitas perguntas perguntando 'como' teste de unidade em um idioma específico, mas nenhuma pergunta perguntando 'o que', 'porquê' e 'quando'.

  • O que é isso?
  • O que ele faz para mim?
  • Por que eu deveria usá-lo?
  • Quando devo usá-lo (também quando não)?
  • Quais são algumas das armadilhas e equívocos comuns
Publicado 04/08/2008 em 17:27
fonte usuário
Em outras línguas...                            


20 respostas

votos
182

O teste de unidade é, grosso modo, testando pedaços de seu código em isolamento com código de teste. As vantagens imediatas que vêm à mente são:

  • Execução dos testes torna-se automatizar-able e repetível
  • Você pode testar em um nível muito mais granular do que apontar e clicar-teste através de uma GUI

Note-se que se o seu código de teste grava em um arquivo, abre uma conexão com o banco ou faz algo através da rede, é mais apropriadamente classificado como um teste de integração. Testes de integração são uma coisa boa, mas não deve ser confundido com testes de unidade. código de teste de unidade deve ser curto, doce e rápido de executar.

Outra maneira de olhar para o teste de unidade é que você escrever os testes primeiro. Isto é conhecido como Test-Driven Development (TDD para o short). TDD traz vantagens adicionais:

  • Você não escreve especulativa "eu poderia precisar isso no futuro" código - apenas o suficiente para fazer os testes passam
  • O código que você escreveu está sempre coberta por testes
  • Ao escrever o teste primeiro, você é forçado a pensar sobre como você deseja chamar o código, que geralmente melhora o design do código no longo prazo.

Se você não está fazendo testes de unidade agora, eu recomendo que você começar a fazer isso. Obter um bom livro, praticamente qualquer xUnit-book vai fazer, porque os conceitos são muito transferíveis entre si.

Às vezes, escrever testes de unidade pode ser doloroso. Quando fica assim, tentar encontrar alguém para ajudá-lo, e resistir à tentação de "apenas escrever o código maldita". O teste de unidade é muito como lavar os pratos. Não é sempre agradável, mas mantém sua cozinha metafórica limpo, e você realmente quer que ele seja limpo. :)


Edit: Um equívoco vem à mente, embora eu não tenho certeza se é tão comum. Eu ouvi um gerente de projeto dizem que testes de unidade fez a equipe escrever todo o código duas vezes. Se ele se parece e se sente assim, bem, você está fazendo errado. Não só escrever os testes geralmente acelerar o desenvolvimento, mas também lhe dá uma conveniente "agora eu sou feito" indicador de que você não teria de outra forma.

Respondeu 04/08/2008 em 17:36
fonte usuário

votos
65

Eu não discordo com Dan (embora a melhor escolha pode ser apenas para não responder) ... mas ...

O teste de unidade é o processo de escrever código para testar o comportamento ea funcionalidade do seu sistema.

testa, obviamente, melhorar a qualidade do seu código, mas isso é apenas um benefício superficial de testes de unidade. Os benefícios reais são:

  1. Torná-lo mais fácil de mudar a implementação técnica ao se certificar de que você não alterar o comportamento (refactoring). Corretamente código unidade testada pode ser reformulado de forma agressiva / limpo com poucas chances de quebrar nada sem perceber.
  2. Dar aos desenvolvedores a confiança ao adicionar o comportamento ou fazer correções.
  3. Documentar seu código
  4. Indicam áreas do código que são fortemente acoplados. É difícil código de teste de unidade que está intimamente ligado
  5. Fornecer um meio de usar a sua API e procurar por dificuldades no início
  6. Indica métodos e classes que não são muito coesa

Você deve testar unidade porque seu de seu interesse para entregar um produto de fácil manutenção e qualidade ao seu cliente.

Eu sugiro que você usá-lo para qualquer sistema, ou parte de um sistema, que modelos de comportamento no mundo real. Em outras palavras, é particularmente adequado para o desenvolvimento empresarial. Eu não iria utilizá-lo para programas / utilitários deitar fora. Eu não iria utilizá-lo para partes de um sistema que são problemáticos para teste (UI é um exemplo comum, mas que nem sempre é o caso)

A maior armadilha é que os desenvolvedores testar muito grande uma unidade, ou eles consideram um método uma unidade. Isto é particularmente verdadeiro se você não entender Inversão de Controle - caso em que os testes de unidade será sempre transformar-se em testes de integração end-to-end. Teste de unidade deve testar comportamentos individuais - e a maioria dos métodos tem muitos comportamentos.

O maior equívoco é que os programadores não deve testar. Somente programadores maus ou preguiçosos acreditar nisso. Se o cara construção de seu telhado não testá-lo? Caso o médico substituir uma válvula cardíaca não testar a nova válvula? Apenas um programador pode testar que seu código faz o que ele pretendia que fazer (QA pode testar casos de ponta - como o código se comporta quando é dito para fazer as coisas que o programador não tinha a intenção, eo cliente pode fazer teste de aceitação - se o código fazer o que o que o cliente pagou por ele para fazer)

Respondeu 04/08/2008 em 17:41
fonte usuário

votos
40

A principal diferença dos testes de unidade, ao contrário de "apenas abrindo um novo projeto e testar esse código específico" é que ele é automatizado , assim repetível .

Se você testar seu código manualmente, ele pode convencê-lo de que o código está funcionando perfeitamente - em seu estado atual . Mas o que dizer de uma semana depois, quando fez uma ligeira modificação nele? Você está disposto a testar novamente-lo novamente com a mão sempre que nada muda em seu código? Muito provavelmente não :-(

Mas se você pode executar os testes a qualquer hora, com um único clique, exatamente da mesma maneira, dentro de alguns segundos , em seguida, eles irão mostrar-lhe imediatamente sempre que algo está quebrado. E se você também integrar os testes de unidade em seu processo de compilação automatizada, eles vão alertar para erros, mesmo nos casos em que uma mudança aparentemente completamente alheios quebrou algo em uma parte distante da base de código - quando nem sequer lhe ocorreu que existe uma necessidade para novo teste que a funcionalidade particular.

Esta é a principal vantagem de testes unitários com os ensaios em mão. Mas espere, ainda há mais:

  • testes de unidade encurtar o ciclo de feedback de desenvolvimento drasticamente: com um departamento de teste separado que pode levar semanas para que você saiba que há um bug em seu código, época em que você já tenha esquecido muito do contexto, assim você pode levar horas para encontrar e corrigir o erro; OTOH com testes de unidade, o ciclo de feedback é medido em segundos, eo processo de correção de bug é tipicamente ao longo das linhas de um "oh sh * t, eu esqueci de verificar essa condição aqui" :-)
  • testes de unidade efetivamente documentar (sua compreensão de) o comportamento de seu código
  • forças de teste de unidade que você a reavaliar suas escolhas de design, o que resulta no design mais simples, mais limpa

estruturas de teste de unidade, por sua vez, se torna mais fácil para você escrever e executar os testes.

Respondeu 14/03/2010 em 18:20
fonte usuário

votos
29

Nunca me ensinaram o teste de unidade na universidade, e ele me levou um tempo para "pegar" ela. Eu li sobre isso, foi "ah, certo, testes automatizados, que poderia ser legal eu acho", e então eu esqueci o assunto.

Demorou um pouco mais antes de eu realmente descobri o ponto: Vamos dizer que você está trabalhando em um sistema grande e você escrever um pequeno módulo. Ele compila, você colocá-lo através dos seus ritmos, ele funciona muito bem, você passar para a próxima tarefa. Nove meses para baixo da linha e duas versões mais tarde alguém faz uma alteração em alguns aparentemente parte independentes do programa, e ele quebra o módulo. Pior, eles testar suas alterações, e seu código funciona, mas eles não testar seu módulo; inferno, eles não podem sequer sabe o seu módulo existe .

E agora você tem um problema: quebrado código é no tronco e ninguém sequer sabe. O melhor caso é um tester interno encontra-lo antes de navio, mas fixação código que no final do jogo é caro. E se não tester interno encontra-lo ... bem, isso pode ficar muito caro, de fato.

A solução é testes de unidade. Eles vão pegar problemas quando você escrever código - que é bom - mas você poderia ter feito isso com a mão. A verdadeira recompensa é que eles vão pegar problemas de nove meses para baixo da linha quando você está trabalhando agora em um projeto completamente diferente, mas um estagiário de verão pensa que vai olhar mais arrumado, se esses parâmetros foram em ordem alfabética - e então o teste de unidade você escreveu caminho de volta falhar, e alguém joga coisas ao estagiário até que ele altera a ordem de parâmetro para trás. Isso é o "porquê" de unidade de testes. :-)

Respondeu 19/09/2008 em 13:45
fonte usuário

votos
12

Lascar em sobre os prós filosóficas de testes unitários e TDD aqui estão alguns dos Eles são fundamentais observações "ampola" que me impressionou nos meus primeiros passos no caminho para a iluminação TDD (nenhum original ou necessariamente notícias) ...

  1. O TDD não significa escrever duas vezes a quantidade de código. código de teste é normalmente bastante rápido e indolor para escrever e é uma parte fundamental do seu processo de design e criticamente.

  2. TDD ajuda a perceber quando parar de codificação! Seus testes dará confiança que você já fez o suficiente para agora e pode parar ajustes e passar para a próxima coisa.

  3. Os testes e o código de trabalho em conjunto para alcançar um código melhor. Seu código poderia ser ruim / buggy. Seu teste poderia ser ruim / buggy. Em TDD você está apostando nas chances de ambos sendo ruim / buggy de ser bastante baixa. Muitas vezes seu o teste que precisa de conserto, mas que ainda é um bom resultado.

  4. TDD ajuda com codificação constipação. Sabe aquela sensação que você tem tanta coisa para fazer que você mal sabe por onde começar? É sexta-feira à tarde, se você apenas procrastinar por mais algumas horas ... TDD permite que você carne para fora muito rapidamente o que você pensa que você precisa fazer, e recebe sua codificação movendo-se rapidamente. Além disso, como ratos de laboratório, eu acho que todos nós responder a essa grande luz verde e trabalhar mais para ver novamente!

  5. Em uma veia similar, estes tipos de designer pode ver o que eles estão trabalhando. Eles podem vaguear fora para um cigarro / / pausa iphone suco e retornar a um monitor que imediatamente lhes dá uma dica visual como para onde eles chegaram. TDD nos dá algo similar. É mais fácil ver onde temos para quando a vida intervém ...

  6. Acho que foi Fowler, que disse: "Os testes imperfeitos, executado com freqüência, são muito melhores do que os testes perfeitos que nunca são escritos em tudo". I interpretar isso como me dando permissão para escrever testes onde eu acho que vai ser mais útil mesmo se o resto da minha cobertura de código é lamentavelmente incompleta.

  7. TDD ajuda a todos os tipos de formas surpreendentes para baixo da linha. testes unitários boas podem ajudar a documentar o que algo é suposto fazer, eles podem ajudá-lo a migrar o código de um projeto para outro e dar-lhe um sentimento injustificado de superioridade sobre os seus colegas não testar :)

Esta apresentação é uma excelente introdução a todos os vínculos de teste bem gostoso.

Respondeu 24/08/2008 em 22:58
fonte usuário

votos
7

Eu gostaria de recomendar o xUnit Testes Padrões livro de Gerard Meszaros. É grande, mas é um grande recurso em testes de unidade. Aqui está um link para o seu site onde ele discute os conceitos básicos de testes de unidade. http://xunitpatterns.com/XUnitBasics.html

Respondeu 14/03/2010 em 19:10
fonte usuário

votos
5

Eu uso testes de unidade para economizar tempo.

Quando a construção de lógica de negócios (ou acesso aos dados) funcionalidade de teste pode muitas vezes envolvem digitando coisas em um monte de telas que podem ou não ser terminado ainda. Automatizar esses testes economiza tempo.

Para mim testes de unidade são um tipo de equipamento de teste modularizado. Geralmente, há pelo menos um teste por função pública. I escrever testes adicionais para cobrir vários comportamentos.

Todos os casos especiais que você pensado ao desenvolver o código pode ser gravado no código nos testes de unidade. Os testes de unidade também se tornou uma fonte de exemplos sobre como usar o código.

É muito mais rápido para eu descobrir que o meu novo código quebra alguma coisa em meus testes de unidade, em seguida, para verificar o código e ter algum desenvolvedor front-end encontrar um problema.

Para os testes de acesso a dados Eu tento escrever testes que ou não têm nenhuma mudança ou limpar depois de si.

Os testes de unidade não vai ser capaz de resolver todos os requisitos de teste. Eles serão capazes de poupar tempo de desenvolvimento e partes centrais de teste da aplicação.

Respondeu 17/09/2008 em 01:38
fonte usuário

votos
5

Esta é a minha opinião sobre ele. Eu diria que o teste de unidade é a prática de escrever testes de software para verificar se o software real, faz o que ele pretende. Isso começou com jUnit no mundo Java e tornou-se uma das melhores práticas em PHP, bem como com SimpleTest e PHPUnit . É uma prática central da Extreme Programming e ajuda você a ter certeza de que o seu software ainda funciona como pretendido após a edição. Se você tem cobertura de teste suficiente, você pode fazer grande refatoração, correção de bugs ou adicionar recursos rapidamente com muito menos medo de introduzir outros problemas.

É mais eficaz quando todos os testes de unidade pode ser executado automaticamente.

O teste de unidade é geralmente associada com o desenvolvimento OO. A idéia básica é criar um script que configura o ambiente para o seu código e, em seguida, exerce; você escreve afirmações, especificar a saída pretende que você deve receber e, em seguida, executar o seu script de teste usando uma estrutura como os mencionados acima.

O quadro será executado todos os testes contra seu código e, em seguida, informar o sucesso ou o fracasso de cada teste. phpunit é executado a partir da linha de comando Linux por padrão, embora existam interfaces de HTTP disponíveis para ele. SimpleTest é baseado na web por natureza e é muito mais fácil de se levantar e correr, IMO. Em combinação com o XDebug, phpunit pode dar-lhe estatísticas automatizadas para cobertura de código que algumas pessoas acham muito útil.

Algumas equipes escrever ganchos de seu repositório Subversion para que os testes de unidade são executados automaticamente sempre que você confirmar as alterações.

É uma boa prática para manter seus testes de unidade no mesmo repositório como a sua aplicação.

Respondeu 05/08/2008 em 00:53
fonte usuário

votos
4

Bibliotecas como NUnit , xUnit ou JUnit são apenas obrigatória se você quiser desenvolver seus projetos usando o TDD abordagem popularizado por Kent Beck:

Você pode ler Introduction to Test Driven Development (TDD) ou o livro de Kent Beck Test Driven Development: por exemplo .

Então, se você quer ter certeza de seus testes cobrem uma "boa" parte do seu código, você pode usar o software como NCover , JCover , PartCover ou qualquer outra coisa. Eles vão dizer-lhe o percentual de cobertura do seu código. Dependendo de quanto você está hábeis em TDD, você vai saber se você praticou bastante bem :)

Respondeu 14/03/2010 em 18:22
fonte usuário

votos
3

Eu acho que o ponto que você não entende é que as estruturas de teste de unidade como NUnit (e similares) irá ajudá-lo a automatizar pequeno para testes de médio porte. Normalmente, você pode executar os testes em uma interface gráfica (que é o caso com NUnit , por exemplo) simplesmente clicando em um botão e, em seguida, - espero - ver a barra de progresso ficar verde. Se ficar vermelho, o quadro mostra que teste falhou e exatamente o que deu errado. Em um teste de unidade normal, você costuma usar afirmações, por exemplo Assert.AreEqual(expectedValue, actualValue, "some description")- por isso, se os dois valores são desiguais, você verá um erro dizendo que "alguma descrição: Espera <expectedValue> mas era <actualValue>".

Assim como um teste de unidade conclusão vai tornar o teste mais rápido e muito mais confortável para os desenvolvedores. Você pode executar todos os testes de unidade antes de cometer novo código para que você não quebrar o processo de construção de outros desenvolvedores no mesmo projeto.

Respondeu 14/03/2010 em 18:25
fonte usuário

votos
3

O teste de unidade é uma prática para se certificar de que a função ou módulo que você está indo para implementar vai se comportar como esperado (requisitos) e também para certificar-se de como ele se comporta em cenários como condições de contorno e entrada inválida.

xUnit , NUnit , MbUnit , etc, são ferramentas que o ajudam a escrever os testes.

Respondeu 14/03/2010 em 18:22
fonte usuário

votos
3

O teste de unidade é sobre como escrever código que testa o código do aplicativo.

A Unidade parte do nome é sobre a intenção de testar pequenas unidades de código (um método, por exemplo) de cada vez.

xUnit está lá para ajudar com este teste - são estruturas que ajudam com isso. Parte do que é automatizado corredores de teste que indicam qual é o critério falhar e quais os que passam.

Eles também têm instalações para código comum de configuração que você precisa em cada teste antes da mão e rasgá-lo para baixo quando todos os testes terminaram.

Você pode ter um teste para verificar se uma exceção esperada foi jogado, sem ter que escrever toda a try catch bloquear a si mesmo.

Respondeu 14/03/2010 em 18:19
fonte usuário

votos
3

Use Testivus . Tudo que você precisa saber está lá :)

Respondeu 17/09/2008 em 01:48
fonte usuário

votos
2

Antes de mais nada, se fala sobre o teste de unidade ou quaisquer outros tipos de testes automatizados (Integração, de carga, testes de interface do usuário etc.), a principal diferença entre o que você sugere é que ele é automatizado, repetível e não requer quaisquer recursos humanos para ser consumido (= ninguém tem que realizar os testes, eles normalmente executado em um apertar de um botão).

Respondeu 14/03/2010 em 18:22
fonte usuário

votos
2

Test Driven Development tem a sorte de tomado o teste de unidade prazo. Como um temporizador velho vou mencionar a definição mais genérica dela.

Teste Unidade também significa testar um único componente em um sistema maior. Este componente único pode ser uma dll, exe, biblioteca de classes, etc. Pode até ser um único sistema em uma aplicação multi-sistema. Então, finalmente Teste Unidade acaba sendo o teste de tudo o que você quiser chamar uma única peça de um sistema maior.

Você, então, passar para testes integrados ou sistema testando como todos os componentes trabalham juntos.

Respondeu 24/08/2008 em 23:34
fonte usuário

votos
2

Unit-teste é o teste de uma unidade de código (por exemplo, uma única função) sem a necessidade de infra-estrutura que aquela unidade de código depende. ou seja, testá-lo em isolamento.

Se, por exemplo, a função que você está testando se conecta a um banco de dados e faz uma atualização, em um teste de unidade que você não pode querer fazer essa atualização. Você iria se fosse um teste de integração, mas neste caso não é.

Assim, um teste de unidade iria exercer a funcionalidade fechado na "função" que você está testando, sem efeitos colaterais da atualização do banco de dados.

Diga a sua função recuperados alguns números a partir de um banco de dados e, em seguida, realizou um cálculo do desvio padrão. O que você está tentando testar aqui? Que o desvio padrão é calculado corretamente ou que os dados são retornados do banco de dados?

Em um teste de unidade você só quer testar se o desvio padrão é calculado corretamente. Em um teste de integração que pretende testar o cálculo do desvio padrão e a recuperação de banco de dados.

Respondeu 15/08/2008 em 18:42
fonte usuário

votos
1

Isso responde por isso que você deve fazer o teste de unidade.


Os 3 vídeos abaixo o teste de unidade de cobertura em javascript, mas os princípios gerais se aplicam na maioria dos idiomas.

Unidade de Teste: Minutos Agora Will Save Hours Later - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

JS Unit Testing (muito bom) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Escrevendo Testable JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Agora estou começando a aprender sobre o assunto para que eu possa não ser 100% correto e não há mais a ele do que o que estou descrevendo aqui, mas o meu entendimento básico de teste de unidade é que você escrever algum código de teste (que é mantido separado do seu código principal), que chama uma função em seu código principal, com entrada (argumentos) que a função exige e o código em seguida, verifica se ele recebe de volta um valor de retorno válido. Se ele voltar um valor válido o framework de testes unitários que você está usando para executar os testes mostra uma luz verde (boa) se o valor for inválido você recebe uma luz vermelha e você, em seguida, pode corrigir o problema imediatamente antes de lançar o novo código para produção, sem testar você pode realmente não ter apanhado o erro.

Então você escrever testes para você código atual e criar o código para que ele passa no teste. Meses mais tarde você ou alguém necessidade de modificar a função em seu código principal, porque o código de teste mais cedo você já tinha escrito para essa função agora executado novamente e o teste pode falhar porque o codificador introduzido um erro de lógica na função ou devolver algo completamente diferente do que essa função deve retornar. Mais uma vez, sem o teste no lugar que o erro pode ser difícil de rastrear, pois ele pode eventualmente afectar outro código tão bem e vai passar despercebida.


Também o fato de que você tem um programa de computador que é executado através de seu código e testa-lo em vez de você fazê-lo manualmente na página do browser por página economiza tempo (o teste de unidade para JavaScript). Vamos dizer que você modificar uma função que é usada por algum script em uma página da web e funciona tudo muito bem para a sua nova finalidade. Mas, vamos dizer também por causa de argumentos que não há outra função que você tem em outro lugar no seu código que depende de que a função recém-modificado para que funcione corretamente. Esta função depende agora pode parar de trabalhar por causa das mudanças que você fez para a primeira função, no entanto, sem testes em lugar que são executados automaticamente pelo seu computador que você não vai notar que há um problema com essa função até que seja realmente executado e você'

Para reiterar, tendo os testes que são executados durante o desenvolvimento de sua aplicação vai pegar esses tipos de problemas como você está codificando. Não tendo os testes no lugar que você teria que ir manualmente através de todo o seu pedido e, mesmo assim, ele pode ser difícil de detectar o erro, ingenuamente de enviá-lo para a produção e depois de um tempo um usuário tipo lhe envia um relatório de bug (que não vai ser tão bom quanto suas mensagens de erro em uma estrutura de teste).


É bastante confuso quando ouvem pela primeira vez sobre o assunto e você pensa consigo mesmo, não estou já a testar o meu código? E o código que você escreveu está funcionando como ele é já deveria, "por que eu preciso um outro quadro?" ... Sim, você já estão testando o seu código, mas um computador é melhor para fazê-lo. Você apenas tem que escrever bons testes suficientes para uma função / unidade de código uma vez e o resto é cuidado para você pelo poderoso CPU em vez de você ter que verificar manualmente que todo o seu código ainda está trabalhando quando você faz uma alteração seu código.

Além disso, você não tem que unidade testar seu código se você não quer, mas vale a pena como a sua base de projeto / código começa a crescer como as chances de introdução de erros aumenta.

Respondeu 18/07/2015 em 18:34
fonte usuário

votos
1

O que você faz se você é dado um monte de porcaria e parece que você está preso em um estado perpétuo de limpeza que você sabe com a adição de qualquer novo recurso ou código pode quebrar o conjunto atual porque o software atual é como um castelo de cartões?

Como podemos fazer testes de unidade, então?

Você começar pequeno. O projeto Eu só entrei não tinha o teste de unidade até poucos meses atrás. Quando a cobertura era que baixo, nós simplesmente pegar um arquivo que não tinha cobertura e clique em "adicionar testes".

Agora estamos até mais de 40%, e nós conseguimos apanhar a maior parte do fruto maduro.

(A melhor parte é que mesmo com esse baixo nível de cobertura, nós já correr em muitas instâncias do código de fazer a coisa errada, e os testes pegou. Isso é uma enorme motivação para empurrar as pessoas para adicionar mais testes.)

Respondeu 22/08/2008 em 19:19
fonte usuário

votos
1

Eu fui a uma apresentação sobre o teste de unidade em FoxForward 2007 e foi dito para nunca mais unidade de teste qualquer coisa que trabalha com dados. Afinal, se você testar em dados ao vivo, os resultados são imprevisíveis, e se você não testar em dados ao vivo, você não está realmente testar o código que você escreveu. Infelizmente, essa é a maior parte da codificação eu faço nestes dias. :-)

I levou um tiro em TDD recentemente, quando eu estava escrevendo uma rotina para salvar e restaurar as configurações. Em primeiro lugar, verifiquei que eu poderia criar o objeto de armazenamento. Então, que tinha o método que eu precisava chamar. Então, que eu poderia chamá-lo. Então, que eu poderia passá-lo parâmetros. Então, que eu poderia passá-lo parâmetros específicos. E assim por diante, até que eu finalmente foi verificado que ele iria salvar a configuração especificada, permita-me alterá-lo, e depois restaurá-lo, por várias sintaxes diferentes.

Eu não chegar ao fim, porque eu precisava-the-rotina de agora, caramba, mas foi um bom exercício.

Respondeu 22/08/2008 em 19:10
fonte usuário

votos
0

Teste de unidade e TDD em geral, permite-lhe ter ciclos mais curtos de feedback sobre o software que você está escrevendo. Em vez de ter uma fase de teste grande no final da execução, você testar de forma incremental tudo que você escreve. Isso aumenta a qualidade do código muito, como você vê imediatamente, onde você pode ter bugs.

Respondeu 03/05/2017 em 09:33
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more