i just need to know what is the objective of Unit Testing.

Para garantir que seu código funcione após as alterações.

what kind of result we expect from unit testing.

Sua mente será alterada. Você vai pensar em como testar o código antes de criá-lo - para que o código seja melhor mantido.

code quality is checked by unit testing?

Não. A qualidade do código não pode ser medida ou verificada por testes de unidade. A qualidade do código pode ser melhorada por revisões de código.

unit testing is the job of developer of tester.

Ambos. Normalmente, o testador cria testes de integração (testes de caixa preta), o desenvolvedor cria ambos (testes de caixa branca e caixa preta).

do i need to maintain a separate copy of the same project for unit testing?

Você deve ter uma cópia separada do projeto para cada desenvolvedor (espero que você o tenha?). O desenvolvedor deve executar testes de unidade antes de se comprometer com o repositório. E o sistema de teste de integração deve levar as alterações para sua própria cópia e executar os testes - o resultado mostrará se todos os desenvolvedores executam os testes antes de confirmar.

Os testes de unidade atendem a vários propósitos relacionados:

• Verifique se os requisitos estão sendo atendidos;
• Desenvolva especificações mais precisas para o código;
• Teste as unidades funcionais isoladamente;
• Torne o teste de regressão mais fácil (por exemplo, certifique-se de não quebrar o código de trabalho).

Verifique se os requisitos estão sendo atendidos

Por exemplo, estou trabalhando em algum código para exibir o histórico de transações de uma conta bancária. Eu tenho uma exigência de que, se eu obtiver um registro de histórico em que valores de taxa, depósito ou juros sejam maiores que 0, eu os dividi em entradas separadas com seus próprios códigos de transação e descrições. Um método em uma classe é responsável por isso, portanto, escrevo código que chama esse método diretamente (ou, se esse método específico não for publicamente visível, chamo o método que chama o método em teste) com entradas conhecidas para cada caso, e, em seguida, verifique os resultados de cada uma dessas entradas para verificar se as subtransações corretas foram criadas, com os dados corretos.

Desenvolva especificações mais precisas para o código

Ao desenvolver seus testes de unidade, você inevitavelmente descobrirá que os requisitos não cobrem todos os casos possíveis. Por exemplo, tenho outro requisito que diz que se o código da transação for X, faça uma coisa e, se for Y, faça outra coisa. Mas não há nada me dizendo o que fazer se o código de transação não é X ou Y. É um buraco na especificação que precisa ser preenchido, neste caso pelo arquiteto. É uma boa maneira de verificar seu trabalho.

De certa forma, o teste unitário torna-se a especificação para o código.

Teste as unidades funcionais isoladamente

Este é um grande problema. O teste de unidade permite testar seu código enquanto você o está escrevendo ; você não precisa esperar até que todas as peças estejam no lugar antes que o teste possa começar. Se você estiver testando uma parte do código que depende de outra classe ou método, você pode escrever uma implementação fictícia dessa classe ou método que retorna valores conhecidos ou se comporta de uma maneira conhecida, para que você possa testar cenários específicos.

Ele também incentiva você a fatorar seu código de forma mais agressiva, reduzindo dependecies entre componentes, o que torna o código mais fácil de manter e estender.

Torne os testes de regressão mais fáceis

O cenário do pesadelo é liberar um patch que quebra o código de trabalho. Ao executar testes de unidade como parte de cada construção, você protege contra quebras acidentais porque o teste associado falhará. Você pode então analisar a falha e ver se a quebra é real (ou seja, alguém codificado em um bug) ou se o requisito / especificação mudou, e ajustar o teste da unidade de acordo.

O objetivo do UnitTesting é simples - reduz o custo de gravação e suporte de um aplicativo. É um nível muito alto. Para o desenvolvedor, há poucos outros como: escrever código melhor, economizar tempo na depuração, facilitar a manutenção, crescimento profissional, afinal.

O UnitTesting é totalmente um trabalho para desenvolvedores, e sim você precisará manter um projeto addional com testes, mas vale a pena esse esforço. (isso não será uma cópia do seu projeto)

O teste de unidade é divertido. É divertido escrever e executar testes. Você não vai entender até tentar.

O Teste de Unidade é todo um modo diferente de escrever código e trabalhar com base de código. Você deve entender isso e todos os membros de sua equipe também. Você precisará executar testes com frequência, configurar o IC, sentir-se feliz.

O Teste de Unidade é tem um bom ferramental e uma grande comunidade, por isso começar a escrever tets não será muito difícil.

Quando você tem Testes de Unidade você não pode dizer que o projeto está brilhando e tudo está ótimo, mas quando você se envolve em projeto sem testes você começa a entender toda a importância deles. / p>     

O teste unitário garante que o contrato funcional de cada "unidade" não seja alterado. Aqui está um exemplo:

For input "A", method X produces result "B"

Ter testes de unidade garante que, mesmo após muitas alterações de código (correções de bugs, novos recursos), o método X ainda produza o resultado "B" quando receber a entrada "A". Se todas as funções do seu sistema forem validadas dessa maneira, a chance de criar bugs ou quebrar acidentalmente a funcionalidade é muito menor.

A prática comum é criar um MyProj.csproj e um MyProj.Test.csproj , em que o projeto Test contém um conjunto de testes para cada contrato no MyProj.

Normalmente, deve haver um teste unitário para cada ramificação condicional / lógica dentro da função que está sendo testada.

Temos feito bom uso de testes unitários em alguns dos projetos em que estou trabalhando. Eu não sou um cara TDD por qualquer meio, então o que eu tendem a fazer é escrever testes de unidade depois de escrever o código e verificar se o comportamento é o esperado.

Quando um bug é selecionado, e o teste de unidade é gravado para verificar se ele não reaparece.

Em seguida, integramos testes de unidade em nosso servidor de integração contínua (TFS 2010) para que, a cada check-in de código, todos os testes de unidade sejam executados se algo em algum outro lugar do código quebrar um teste de unidade. e podemos corrigi-lo antes de liberar.

Ter uma abordagem disciplinada para testes de unidade também acaba mudando a maneira como você codifica. Você tende a escrever códigos projetados mais coesos e fracamente acoplados, porque é isso que facilita o teste de unidade. Como um subproduto, a qualidade do código é aprimorada. Técnicas de arquitetura como o DI / IOC gretaly facilitam o teste de unidades.

Com o teste de unidade, você quer que o teste seja totalmente previsível e não tenha dependências no ambiente, como bancos de dados, etc. Isso significa que você utiliza coisas como mocks e stubbs para fornecer esses serviços externos.

Os testes de escrita podem ser bastante complexos, particularmente ao zombar dos componentes do sistema. IMHO é um trabalho para os desenvolvedores, porque é programação e, além disso, eles não devem a lógica do código de volta para a frente. O runnning do teste, como eu disse antes, é o trabalho do agente de teste, como o Visual Studio manualmente ou o TFS.

Cada "unidade" tem um contrato implícito: aproximadamente, "se você fornecer essas entradas, eu lhe darei essas saídas". Testes de unidade servem para provar que o contrato foi cumprido e avisam quando ele foi quebrado.

Eles são úteis se você os escrever primeiro (tdd), pois você sabe que está pronto quando todos os testes passarem (assumindo que todos os testes são uma representação justa do contrato). Depois que o código tiver sido escrito, os testes da unidade informarão quando uma alteração interromper o contrato.

Por exemplo, digamos que você tenha uma função que converta uma string para todas as maiúsculas. Você testes de unidade devem provar que, dada uma string, ele faz exatamente isso. Mais tarde, alguém passa em uma string unicode e sua função falha. Isso quer dizer que as entradas unicode não faziam parte do contrato, então você tem que adicionar um novo recurso, ou era parte do contrato e o teste está dizendo que o código tem um bug e isn honrando o contrato.

Você não apenas obtém os benefícios da detecção de erros, mas o próprio ato de escrever os testes de unidade ajuda você a entender completamente o que seu código deve fazer. Isso faz você pensar em casos de borda, sobre quais entradas são necessárias e quais saídas são esperadas.

Evitando regressões

(teve que declarar isso em voz alta e clara)

As regressões são tão incrivelmente relevantes é inacreditável que a maioria das escolas ainda não se incomode em mencioná-las.

Aqui, leia o artigo da Wikipedia sobre Teste de regressão . É uma introdução estruturada ao tópico e destaca os testes Unidade e Funcional . (uma distinção que muitos tutoriais negligenciam, mas, em seguida, testes funcionais, geralmente não precisam de estruturas ou de açúcar de sintaxe)

Regressões em código obviamente não desaparecem magicamente com testes, mas os poderes combinados de VCS e Teste Unitário ajudam a pegá-los desde o início e a agir sobre eles com fúria viking.