Transcrições
1. Apresentação: Olá. Bem-vindo ao curso sobre testes de software eficazes
com D Net na Unidade EX. Bem, para começar,
deixe-me me apresentar. Meu nome é Cayo Susa. Atualmente trabalho como arquiteto de
software e estou
na área de desenvolvimento de software há mais de dez anos. Neste curso, espero
poder compartilhar minha experiência. Que você possa aprender sobre testes
de software e como tornar os testes de software eficazes quando
se trata de testes unitários. Também darei uma visão geral
dos fundamentos do teste de software e tentarei ajudá-lo
a entender
por que devemos testar E quais são alguns
dos tipos de
teste de software que existem? Bem, primeiro, vou começar falando sobre os fundamentos do teste de
software Analisaremos e exploraremos
a pirâmide de testes. Abordaremos testes teóricos
e unitários, testes de
integração, testes manuais e de
sistema. Você será capaz de
entender por que e quando aplicar cada uma dessas estratégias de
teste. Também analisaremos um estudo
de caso
que envolve
bolsas de estudo universitárias Com base nesse estudo de caso, usaremos técnicas de
teste unitário para testar a lógica e
validar alguns casos extremos Você entende a importância do teste
unitário e como isso
pode reduzir os riscos quando se
trata de fazer
alterações no código e validar as regras de negócios
existentes. Exploraremos os
fundamentos da unidade
X e entenderemos
por que usar essa ferramenta Lá,
implementaremos o código em que você implementará testes
unitários e
examinará a biblioteca de unidades X e as funcionalidades
para testes unitários Como parte deste curso, também
exploraremos outras bibliotecas que oferecem suporte testes
unitários, como afirmações
fluentes Examinaremos práticas comuns , como o uso do explorador de testes do Visual
Studio, testes
de formatação e
padrões, como a cobertura de um padrão e código Em seguida, analisaremos os
requisitos para o teste. Aplicaremos testes unitários com base nos requisitos de software. Simularemos o acesso aos dados para facilitar os testes unitários e analisaremos nossos testes
com cobertura de código Convido você a se juntar a mim
nesta empolgante experiência de
aprendizado que o ajudará
a chegar ao próximo nível. Meu objetivo é que,
após este curso, você tenha aprendido os fundamentos do
teste de software Você terá
confiança para criar testes de
unidade usando bibliotecas
comuns. Você poderá
criar testes unitários de forma eficaz nos
aplicativos.net Por fim, espero que essa
experiência possa proporcionar crescimento
técnico e conhecimento no campo da
engenharia de software.
2. Fundamentos dos testes de software: Olá, aí. Bem-vindo à aula sobre
os fundamentos
do teste de software Então, vamos falar sobre por que
alguém testaria um software. Portanto, uma falha de software pode comprometer um
projeto ou organização individual. Dependendo do bug
do software, um erro pode comprometer toda
a operação. Imagine que você está implementando
um software financeiro
e, devido a um grande bug, milhões de dólares são
perdidos em transações. Isso pode comprometer
sua organização, o projeto em que você está trabalhando e também você como indivíduo. Qualidade do software. Como
engenheiro de software, é sua responsabilidade
garantir a qualidade do
software que você produz. A implementação de software de alta
qualidade também
pode levar ao crescimento. O terceiro ponto é a segurança. Ter um software seguro
é essencial para se proteger contra ataques
maliciosos e evitar violações de dados Você pode pensar em
testar autenticação, autorização de
teste, teste de
penetração e
muito mais custos, economizando tempo e dinheiro para sua
organização, o
teste é uma das formas mais
econômicas de garantir
a qualidade e a confiabilidade
do seu software. Finalmente, há muitos
outros motivos pelos quais os testes podem ajudar. Você
vê isso explícita ou implicitamente ao longo deste curso Então, vamos nos aprofundar um pouco mais no que diz respeito ao
custo do teste de software. O custo dos bugs que ocorrem na produção geralmente supera
o custo da prevenção Imagine um aplicativo de negociação de ações
inativo por 2 horas devido a um bug no código que poderia ter sido evitado com testes unitários
adequados. Calcule o esforço
necessário para depurar um erro, fazer as alterações no código e, em seguida, implantar mais o custo de recursos
humanos Se nenhum teste for considerado, erros podem ser comuns
no processo de desenvolvimento. Quando os desenvolvedores enviam o código para um ambiente
específico, controle de qualidade encontraria defeitos Ele voltaria para o
desenvolvedor que o consertaria e, em
seguida, o código entraria
em produção. Você já deve ter ouvido falar que
o teste é um processo demorado, mas a prática leva à perfeição Desenvolvedores que têm
testes como parte de seu ciclo de vida de desenvolvimento
geralmente têm melhores resultados. Quais são algumas das desculpas para testes de
software? Às vezes, a responsabilidade é transferida para a equipe de
garantia de qualidade ou QA. No entanto, o controle de qualidade não pode testar
todas as alterações no código, pois geralmente não está ciente
de todas as alterações no código. Meu software tem alguns bugs. Mesmo
softwares bem arquitetados com engenheiros
experientes trabalhando
neles ainda devem apresentar bugs, especialmente com o
crescimento da equipe, do tamanho, linhas de código e dos padrões, não fazem parte dos requisitos Os requisitos de software
devem defender testes por meio da entrada de requisitos
não técnicos. Muito demorado
e caro. Como
mencionado anteriormente, corrigir bugs
de produção tende a ser mais caro do que
evitá-los. Não é necessário para entrega. O teste de software
pode fazer parte da entrega. Táticas que automatizam
e executam testes com análise de cobertura de
código
podem fazer parte de um pipeline de entrega Vamos dar uma olhada em alguns princípios. Então, posso testar tudo? Testar todos os cenários
no software
não é viável devido
ao número de combinações
e cenários
possíveis que
podem aparecer à medida que o software evolui É preciso priorizar
o que deve ser testado, e falaremos
sobre isso quando
chegarmos à seção sobre os
tipos de teste de software Quando devo parar de testar? O objetivo é descobrir quais tipos de testes
fazem mais sentido para o software que você
está desenvolvendo e qual parte do software você
deve priorizar Com isso, você saberia quando
parar de testar ou quando fazer o
teste. Onde fazer o teste. Alguns recursos do software são
mais importantes do que outros, como um
módulo de transação bancária pode ter maior prioridade do que uma seção
de notificação de um software. Teste perfeito. Não
existe um software perfeito para testes. Como afirma **** Straw, os testes podem ajudar a
encontrar a presença de bugs, não a ausência deles Não há software livre de bugs.
Finalmente, condições. Um software diferente pode
exigir testes diferentes. Um aplicativo web pode exigir
estratégias diferentes de um aplicativo para desktop que
difere de um aplicativo móvel.
3. Teste de unidade: Olá. Bem-vindo à
aula sobre testes unitários. Portanto, os testes unitários são pequenos, pois o nome indica unidade. Quando o objetivo é testar um
único recurso de um software, teste
unitário é uma ótima opção. Teste de Unidade valida uma unidade ou parte de uma pequena
seção do código Os testes unitários são rápidos.
Eles são pequenos e rápidos. Normalmente, o teste unitário
abrange um método dentro de uma classe se você estiver trabalhando em programação orientada a objetos. Na maioria dos casos, eles
testam uma parte
do método ou o comportamento
de um único método. Portanto, você teria
vários testes unitários testando um único método
para vários comportamentos. Vamos dar uma olhada em algumas
das vantagens. Conforme mencionado anteriormente,
eles são rápidos. Eles devem ser fáceis de controlar
porque são pequenos. Eles devem ser fáceis de escrever
porque são pequenos. E também servem
como documentação. Vamos dar uma olhada em algumas
dessas vantagens. Às vezes, eles carecem de
realidade porque
testam uma
seção tão pequena do código. Como são unidades de teste, ele não detecta todos os bugs, pois não está testando métodos de comunicação
entre si E essa é uma das
maiores desvantagens. Bem, com o teste unitário,
podemos medir a cobertura do código. Por definição, uma
métrica de cobertura mostra quanto
código-fonte uma suíte de testes executa,
de nenhum a 100% É comum ouvir que
quanto maior a cobertura fria, maior
a qualidade do código. Embora a cobertura fria possa
fornecer feedback valioso, ela não fornece
feedback preciso sobre testes eficazes. No entanto, é
importante entender a cobertura
do código e aplicar a cobertura
fria quando necessário. Então, vamos dar uma olhada na cobertura fria. A cobertura do código consiste basicamente em
linhas de execução ou linhas de código e execução divididas pelo total de
linhas de código. As métricas de
cobertura do código ou
do teste mostram a proporção desses dois itens. E isso nos ajuda a entender quanto do nosso código
foi testado. Quando se trata de cobertura de
agências, são basicamente as
agências percorridas, divididas pelo total A cobertura da filial mostra
quantas estruturas de controle, como instruções
switch e nif, são percorridas
por pelo menos um
teste na E então temos a
lógica central ou os problemas com as métricas. Isso não garante o
teste da lógica central. Portanto, você pode ter uma alta cobertura de
código e ainda não testar
sua lógica central
do aplicativo, pois
essa lógica tem mais a ver com a forma como você escreve seu teste do que com a escrita de
testes. Para continuar, vamos examinar os testes unitários
eficazes. Eles devem ser de baixo
custo e alto valor. Eles podem ser automatizados e se concentram na parte
essencial do código.
4. Testes de integração: Olá. Bem-vindo à
aula sobre testes de integração. Então, falamos sobre testes
unitários, certo? Eles são rápidos. Eles testam
a unidade de aplicação. No entanto, você não pode
ter certeza de que seu sistema funciona se você confiar
apenas em testes unitários. Pode ser necessário validar como
diferentes partes do software se integram entre
si e com sistemas externos, como banco de dados,
barramento de mensagens, sistemas de e-mail etc teste de integração
ajuda a validar como os componentes funcionam em integração
com sistemas externos Quando você pensa em testes de
integração, é importante manter um equilíbrio entre os testes unitários
e de integração. Os testes de integração validam
as integrações com sistemas
externos Portanto,
os testes de integração tendem a ser mais caros de
manter do que os testes unitários. Esses testes normalmente
executam mais código do que testes de unidade porque são executados
por meio de dependências externas Isso melhora a proteção
contra regressões. Mais do que testes unitários. teste de regressão se refere a uma
técnica de teste de software que executa testes funcionais e
não funcionais para garantir que um aplicativo de software funcione conforme esperado após a realização de quaisquer alterações, atualizações, revisões,
melhorias, otimizações, etc O número de testes entre a
integração e a unidade pode diferir
drasticamente
de aplicativo para aplicativo,
dependendo das necessidades Então, vamos falar sobre quando
aplicar o teste de integração. teste de integração valida
como o software se integra
aos sistemas
e dependências externos E quando se trata
dessas dependências, analisamos dois tipos A primeira são
as dependências de controle, nas quais você tem controle total, como métodos
de acesso aos dados no banco de dados A segunda são dependências
não controladas, nas quais você não
tem controle total, como uma biblioteca de barramento de serviço E se eu não conseguir acessar as dependências
de controle? Então, digamos que, por motivos
de segurança, você não tenha acesso
a um banco de dados real para suas dependências de controle Nesse caso, você
deve evitar escrever testes de
integração
porque eles fornecem baixo valor. Os testes precisam fornecer valor. Concluir. O
teste de integração valida como os componentes funcionam na integração
com sistemas externos Eles cobrem a
camada de apresentação, como controladores, e protegem melhor
contra a regressão Embora estejamos abordando
isso em um nível muito alto, os testes de
integração
são muito importantes. Eles não são o
objetivo deste curso, pois focaremos em
mais testes unitários. No entanto, entender os
tipos de testes disponíveis é crucial quando se trata de
planejar os testes. Sim.
5. Testes de ponta a ponta: Olá. Bem-vindo à
aula sobre testes intencionais. Os testes finais consistem em
testes que abrangem fluxo de trabalho do
aplicativo que
geralmente é feito por uma
pessoa ou por um programa. Esses testes ajudam a validar sistemas em que todos os seus componentes são levados em consideração, como banco de dados, barramento
de serviço, interface do usuário
e outras integrações A interface do usuário, como a navegação na plataforma ou no
navegador, e o processamento de back-end
também são abordados em dez testes. teste Enten abrange a funcionalidade de todo o
aplicativo de software com simulação
real do usuário final e replicação de dados factuais Nesse ponto, o código ou
banco de dados é irrelevante. A ideia é fornecer uma
entrada para o sistema e esperar uma saída por meio do
mesmo processo do usuário final. Os testes finais são realistas. Portanto, fazendo
esse tipo de teste, você deve usar uma plataforma na qual o sistema
esteja sendo executado. Você pode usar um navegador da Web
para verificar um aplicativo da Web. Você pode usar um
iPhone para validar um aplicativo IOS ou Windows para testar um aplicativo de
desktop A ideia é que você esteja usando o
que o
usuário final usará. Certo? Então, se você pensar em um carro, você tem um motor
e pode testar seu motor ou partes
do motor, esse seria seu teste unitário. Se você quiser testar
como o motor funciona com outras partes do carro, esse seria seu teste de
integração. E então seu teste de dez
seria, na verdade entrar no carro e
dirigir o veículo. Vamos dar uma olhada em algumas
das vantagens. Primeiro, os testes são mais realistas. Os métodos não são
testados isoladamente. Em vez disso, você
simula o teste
da plataforma desejada
com entradas e saídas Eles são confiáveis
para regressão. O teste pode
passar por todas as camadas
do aplicativo,
começando pelo front-end. E também aumentam
a confiança. Para a equipe de garantia de qualidade, os testes duplos
finais podem ser usados como uma etapa final antes da liberação para produção, com a certeza de que a
funcionalidade existente não foi interrompida Vejamos algumas
das desvantagens. Primeiro, desempenho. Os testes do sistema geralmente
são lentos
em comparação com o teste unitário. Imagine tudo o que um
teste de sistema ou dez testes precisa fazer, incluindo iniciar e executar todo
o sistema com
todos os seus componentes. O teste também
precisa interagir com aplicativo
real e as ações podem levar alguns segundos
ou até minutos. Segundo, configuração do ambiente. Os testes também são mais difíceis de escrever. Alguns dos componentes,
como o banco de dados, podem exigir uma configuração complexa antes serem usados em um cenário
de teste. Pense em conectar a
autenticação e
garantir que o banco de dados tenha todos os
dados exigidos pelo caso de teste. Um código adicional é necessário
apenas para automatizar o teste. A variação do comportamento. Às vezes, o mesmo
teste pode ter resultados de comportamento
diferentes
, dependendo das integrações. Imagine um teste de sistema
que exercita um aplicativo web. Depois que o testador
clica em um botão, uma solicitação HTTP para o aplicativo web demora meio
segundo a mais do que Devido a essa pequena variação
que muitas vezes não controlamos, o teste pode falhar, certo? O teste é executado novamente, e o aplicativo web leva
o tempo normal para responder, e o teste é aprovado. Muitas incertezas no teste
do sistema podem levar a um comportamento inesperado
6. A pirâmide de testes: Oi, aí. Bem-vindo à
aula sobre a pirâmide de testes Ao trabalhar com testes,
é importante primeiro ter uma compreensão clara
dos diferentes níveis de teste,
seus prós e contras. Portanto, sua equipe pode investir no que
fizer mais sentido para o objetivo da organização
ou dos projetos em questão. A pirâmide a seguir contém
todos os níveis de teste. Se você pesquisar testando o Pyramid, deverá encontrar algumas variações
delas. Primeiro, temos o
teste unitário na parte inferior. Bem, todas as principais
regras de negócios podem ser testadas. Em segundo lugar, temos
testes de integração em que você tende a ter mais complexidade devido
às integrações com serviços
externos, e eles tendem a ser escritos para menos cenários do que os testes unitários Finalmente, temos que
terminar os testes na parte superior. Ele abrange a funcionalidade de todo
o aplicativo de software
e tende a ser mais complexo de escrever e manter devido às possíveis alterações
no aplicativo. Conforme visto na
figura, a parte inferior
da pirâmide é menos
realista e menos complexa, tende a ser mais fácil de manter E à medida que você sobe na pirâmide, complexidade e a capacidade de
manutenção Os testes unitários são fáceis de
escrever. Eles são rápidos. Eles se combinam com a experiência dos
desenvolvedores e podem ser lançados junto
com o código de produção. Para o teste de integração, o foco é testar as integrações, e isso pode não se aplicar a
uma grande parte do código Pode haver cenários
específicos em que faça mais sentido fazer testes
de integração. Finalmente, seus testes podem ser
mais complexos de manter, especialmente se
forem automatizados. Muitas organizações têm
uma equipe especializada apenas para esse fim
, como a Kiwi O foco deste
curso será em testes
unitários. Então, vamos resumir O objetivo do teste de
software é encontrar a
presença de bugs. Embora existam
vários tipos de testes, testar tudo
na maioria dos sistemas não
é viável ou possível Finalmente, temos os níveis de teste. Existem diferentes níveis de teste, desde pequenos testes unitários até
testes que se integram
a serviços externos e cada um fornece seu
próprio valor exclusivo Portanto, é importante que você, como engenheiro
de software, analista de controle ou alguém envolvido
em um projeto
de software , entenda cada um desses tipos de teste, seu nível e quando se inscrever. Convido você a se juntar a mim
nessa jornada para se aprofundar, aprender novas habilidades ou
atualizar as habilidades existentes. O objetivo é
que você entenda, implemente e aplique testes unitários ao seu aplicativo de software. Se você quiser crescer como engenheiro
de software, analista de garantia de
qualidade
ou aprender sobre testes, esse caminho é ideal para você
7. Apresentação de estudo de caso: Oi, aí. Bem-vindo à aula sobre uma apresentação de
estudo. Então, vamos falar sobre o estudo
Cesar Scholarships K. O Cesar College concede
uma bolsa de estudos para 50% de seus candidatos com
base na média de
notas do ensino médio Após o término do
prazo de inscrição, as inscrições são avaliadas e metade dos
alunos é premiada Uma lista dos alunos premiados é enviada ao setor
responsável. Agora vamos pensar em como
implementaríamos isso no código. Primeiro, criaríamos um método chamado calcular candidatos
premiados O método
receberia uma lista de estudantes e devolveria os alunos elegíveis
para a bolsa A entrada é a lista
dos nomes dos alunos em suas respectivas
notas médias. O resultado é a lista
dos alunos premiados. Aqui está um trecho de código do método de cálculo
dos candidatos
premiados A primeira parte do código é
usar uma biblioteca.net chamada Link para ordenar os candidatos na lista
pela média de notas A segunda parte do
código é manter metade
dos elementos na lista e
retornar a segunda metade. Como a lista de candidatos é ordenada do
menor para o maior, essa implementação
deve retornar metade dos alunos com
o GPA mais alto Agora, o desenvolvedor executa seu aplicativo e
faz um caso de teste, e ele funciona, como você
pode ver nesta figura. Temos Kyle e Luena
com o maior GPA, e o programa retorna os alunos premiados
corretamente Neste momento, como desenvolvedor, você está satisfeito com o resultado e implanta seu
código na produção. Você está trabalhando em uma equipe pequena e não há membros kiwis, algo muito típico
em algumas organizações No entanto, algumas
horas depois, você recebe uma ligação do cliente informando que o aplicativo não
funciona conforme o esperado. Na próxima lição,
analisaremos o que aconteceu e como o teste unitário pode ajudar a evitar esses problemas.
8. Como aplicar testes de unidade: Aqui, bem-vindo à lição sobre teste unitário aplicado
a um determinado caso de uso. Então, vamos examinar o método de cálculo de candidatos
premiados. Aqui está o trecho de código do
método. E vamos analisar essa
lógica muito rapidamente. A primeira parte basicamente ordena os alunos
pela média de notas. A segunda parte é cortar metade dos elementos e
devolver a segunda metade Como a lista está ordenada, retornamos a segunda metade
dos alunos com
o maior GPA Então, aqui temos um exemplo de um teste unitário
escrito para esse método. Por enquanto, não se preocupe com a convenção de nomenclatura ou com a
forma como ela foi criada O objetivo desse teste
é validar se a lista de candidatos está vazia quando nenhum candidato Quando temos um padrão oh oito que examinaremos
no próximo módulo,
temos o arranjo, o ato
e a afirmação, como você pode ver Para este teste,
organizamos uma lista vazia. Chamamos o método, calculamos os candidatos
premiados e armazenamos isso
na variável de resultado Por fim, validamos ou afirmamos
se o resultado está vazio, que é o resultado esperado Portanto, o teste foi aprovado no código
RNR sem precisar
executar o aplicativo real Aqui temos um segundo teste unitário. O objetivo deste teste
é devolver metade
dos candidatos com base
nos candidatos enviados Organizamos a lista de candidatos
enviados e a
armazenamos em uma variável real Em seguida, criamos uma lista
dos candidatos esperados e armazenamos na variável
esperada O método é então chamado e os candidatos são armazenados
na variável de resultado Em seguida, validamos se
os candidatos esperados
são os mesmos que os O teste foi aprovado e agora estamos
mais confiantes de que o código
está funcionando conforme o esperado. Aqui temos nosso terceiro teste unitário que valida um candidato Depois de escrever o
terceiro teste unitário, você começa a
questionar casos extremos. Se dois candidatos se inscreverem, devemos devolver apenas um? Questionamos os proprietários do produto e eles dizem que devemos ter mínimo dez
alunos premiados. Depois que os requisitos
forem atualizados, executamos os testes novamente
para dez candidatos, esperando que esses dez
candidatos sejam devolvidos Basicamente, fazemos
nosso teste para falhar, mas para seguir uma
nova regra de negócios. Executamos o seguinte teste, ele falha porque retorna
metade dos candidatos Agora implementamos uma
mudança no código. Aqui, verificamos o
número de candidatos. Se o total de candidatos
for menor que 11, devolveremos todos os candidatos Em seguida, executamos o teste unitário
novamente e ele passa. No entanto, ainda está
faltando alguma coisa. Você consegue pensar no
que está faltando? E se 12 pessoas se inscreverem? O programador retorna seis. Vou deixar você
descobrir como resolver isso. O objetivo aqui é mostrar como a Unitest pode ajudá-lo a validar a lógica
de negócios de sua aplicação e fazer alterações em seu
código com mais confiança Muitas vezes vejo que os
erros que os desenvolvedores cometem estão em pequenos detalhes que a Unitest pode ajudar e deve ajudar a evitar Ao escrever testes unitários, isso ajuda você a pensar de forma
mais sistemática Se começarmos a analisar
outros casos, podemos pensar em coisas como: e
se todos os GPAs forem iguais E se o GPA
for menor que um? Com a estratégia de teste unitário, você pode fazer alterações em
seu código sem precisar se preocupar em quebrar a funcionalidade
existente. Depois de ter testes
que cubram esses casos, devem ser um incentivo
confiável para todos os desenvolvedores, pois eles agregam mais valor à equipe e oferecem projetos de alta
qualidade O código desta lição
será anexado ao curso.
9. Começando com Xunit: Bem-vindo à palestra sobre
Introdução ao xUnits. Portanto, o Xnit é uma ferramenta de teste
unitário gratuita, de código
aberto e focada na comunidade Escrito pelo
inventor original do N Unit Version two, Xnit é a tecnologia mais recente para testes unitários em C sharp,
FSAP, visobsic.net X Unit funciona com R
Sharper Cold Rush, Test driven.net, Xamarin Faz parte da Fundação.net e atualmente está
licenciado sob o Apache 2 Então, por que você deve usar o Xnit? Bem, ela é bem usada
pela comunidade e provou
ser uma ótima biblioteca. Como você pode ver, existem
mais de 450 milhões de downloads no Nugget até hoje Ele recebia atualizações
e melhorias constantes mensalmente, às vezes mais de
uma vez por mês. É uma biblioteca bem projetada baseada em
uma
biblioteca muito robusta
chamada In Unit, e sua versão atual é 2.80 Se você está assistindo a este vídeo, tenho certeza de que essa
versão já está atualizada ou que a 2.80 não é
a versão mais recente Bem, a partir de agora, a maioria
dos exemplos será
implementada no Live Code. Vou implementar os exemplos
neste módulo usando o Visual
Studio Professional 2022. No entanto, se você estiver
usando o Windows, eu recomendo a
versão gratuita do Visual Studio. Essa é a versão da comunidade e tem todas as funcionalidades
que usaremos ou que usarei no
Visual Studio 2022 Você pode baixar o Visualstudio em
visualstudio.microsoft.com . Se você estiver em um Mac ou Linux, você pode baixar o
Visual Studio Code. Tudo bem, então vamos começar com algumas implementações básicas Para começar, primeiro você
abrirá o Visual Studio
e criará um novo projeto em branco. Eu já tenho meu
projeto em branco criado aqui. Basicamente, é apenas um modelo onde podemos inserir
novos projetos. Se você quiser criar
um novo projeto em branco, basta clicar em Arquivo Novo Projeto
e selecionar Solução em branco, e é basicamente isso. Depois de criar sua solução
Blank, ou você pode usar a
existente da última aula, coloquei o link para download
como parte da palestra Assim, você pode baixar o
existente ou criar um do zero,
assim como estou criando aqui. Então, o que você vai fazer é
clicar com o botão direito
do mouse na solução e adicionar um novo projeto. Vamos seguir em frente
e selecionar a Biblioteca de Classes. Se você não o vê aqui, pode pesquisar aqui. Biblioteca de classes. No nosso caso, estamos focados no C nítido, certifique-se de ver o C nítido
aqui e clique em Avançar. Essa biblioteca é
basicamente uma nova camada. Essa camada vai conter
a lógica de negócios para os testes que
vamos criar. Vamos dar a esse ponto comercial o nome
de César. Você pode chamá-lo do
que quiser. Eu recomendo o prefixo
business apenas para contextualizar. Em seguida, vamos seguir
em frente e escolher Det eight. Realmente não importa
a versão.net aqui. Se for padrão ou sete ou
oito ou mesmo nove ou dez, qualquer versão que você veja, já que vamos implementar
algumas funcionalidades básicas. Então, vou escolher Det eight
e
criar, e isso criará
uma nova camada de negócios ou uma nova biblioteca de classes que representamos como uma camada de
negócios. Então, agora vamos seguir em frente e
implementar alguma lógica. Então, vamos renomear isso. Então, vou clicar com o botão
direito do mouse em Renomear a classe um para calculadora E vou seguir em frente
e adicionar um método de adição. Então, vou apenas
colar o método add. Então isso é um anúncio. Ele
retorna A mais B e tem
os parâmetros A e B. Portanto, temos nossa camada de
negócios e nossa classe de calculadora. Implementação muito simples.
Posso clicar com o botão direito do mouse aqui, clicar em
Construir apenas para ter certeza de
que não temos erros. A construção foi bem-sucedida, e
é basicamente isso. Agora, vamos continuar e
clicar com o botão direito do mouse na solução novamente, clicar em Adicionar novo projeto. Vamos adicionar uma
nova camada de teste, certo? Então, vamos selecionar
um projeto de teste de unidade X. Então, a mesma coisa
aqui, se você deveria fazer um teste,
sim, aqui está. Há uma seção de teste aqui, então eu estou procurando por C Sharp. Posso até escolher o teste de
todas as plataformas. E, como você pode ver,
há teste MS, unidade
N, teste unitário ou projeto de teste unitário
para o framework net. E, neste momento,
estamos focados na Unidade X. Mas eu só quero
mostrar que, você sabe, há muitos projetos de teste muito
bons aqui. Então, vamos seguir em frente e focar
nossa missão aqui nas unidades X. Então, vou escolher o modelo de
unidade X para C Sharp, não
quero Det framework e estou no Det eight.
Clique em Avançar. Vou chamar esse negócio de pontos
César porque estamos testando
a camada de negócios Na verdade, vamos dar um
nome a essa empresa. Acho que inverti acidentalmente, mas tudo bem, teste de
pontos Cesar de negócios Normalmente,
costumo fazer algo como Cesar Dot Business,
mas tudo bem O importante aqui
é que entendamos que esse projeto de teste está testando o projeto Business Dot Cesar Então, como você pode ver, o prefixo
é business dot Cesar. E então o sufixo é teste. Portanto, este é um
projeto de teste que está testando a camada Business
Dot Caesar Então, eu gosto de deixar
isso bem explícito. Quando clico em Criar, vemos dois projetos em
nossa solução. Temos o business dot Caesar, onde temos nossas regras de negócios e o teste business
dot Cesar dot, onde temos nossos testes unitários
para as regras de negócios Como você pode ver, se eu
clicar no projeto, você verá a estrutura de destino. Você verá algumas bibliotecas que estão dentro deste projeto. Assim, você pode ver a estrutura de
destino que especifica a estrutura
do projeto Você pode ver implícitos usando notavelmente os pacotes
que ele inclui Portanto, inclui as unidades X, que são basicamente o pacote que contém a estrutura
de teste. Você tem o X Unit
runner dot Visual Studio e o microsoft.net dot test dot
SdK Basicamente, eles são
necessários
para que você execute seu projeto de teste
no Visual Studio. Você também tem outras bibliotecas,
como o coletor coberto, que permite coletar cobertura de
código, se é isso
que você costuma fazer Agora vamos continuar e
terminar a aula, certo? Criamos nosso projeto. Criamos nosso projeto de teste. Podemos clicar com o botão direito do mouse na
solução e criar. Tudo está sendo construído
com sucesso. E então, na próxima lição, escreveremos um teste unitário. E também neste projeto, você pode baixar
este modelo na seção
de download do curso.
10. Trabalhando com o Test Explorer: Olá. Bem-vindo à lição sobre como trabalhar
com o Test Explorer. Na última palestra,
criamos nosso teste e criamos nosso projeto de teste e
criamos nosso projeto Business
Dot Caesar Em nosso ponto comercial Caesar, temos uma calculadora básica
e, no projeto de teste,
se você criar um projeto de teste, ele cria automaticamente
uma classe de teste unitário Aqui temos um
atributo de fato que representa um método de teste e esse método de teste
é chamado de teste um. Temos uma classe de teste
e um método de teste. Agora vamos
explorar esse método de teste. Vamos clicar na guia de teste aqui e depois
clicar no Test Explorer. O explorador de testes é o nome
da janela que permite que
você navegue e execute seus testes ou testes de unidade
no Visual Studio, certo? Você tem
alguns grupos aqui, como este primeiro grupo, que permite
que você execute seus testes, para que eu possa executar todos os testes. Eu posso executar testes selecionados, para que eu possa realmente selecionar o
teste que eu quero executar. Nesse caso, há apenas um, e eu posso executar esse único teste. Posso repetir a última execução
e, em seguida, também posso
executar meu teste que falhou. Segunda aba aqui ou
segunda seção aqui, você pode filtrar
seus testes, certo? Então você tem o total de
testes. Você pode filtrar. Todos eles, eu posso filtrar,
os testes de aprovação. Então, se eu clicar aqui, já que não
há teste de aprovação, já que eu não executei nada, ele simplesmente não mostra nada. Eu posso filtrar o teste com falha e posso filtrar os
testes que não foram executados Então, se eu clicar aqui,
você pode ver que esse teste ainda não foi executado, então é esse avião aqui
dentro do Test Explorer. Então, a última seção aqui é um lugar onde você
pode configurar seu teste. Você tem
opções avançadas, como alterar a arquitetura do processador e executar
automaticamente seus
testes após cada compilação de teste Você tem as opções,
algumas opções aqui. Então, isso é apenas para configurar como você deseja que
a ferramenta se comporte, e você pode explorar isso, se
quiser, alguma personalização Agora, vamos
escrever alguns testes, certo? Então, primeiro, vou
fazer esse teste, então vamos executá-lo. Clique em Executar. E como
você pode ver aqui, deixe-me clicar aqui para que eu
possa mostrar todos os testes. Você pode ver
que passou, certo? Portanto, um teste falhará quando
falhar explicitamente. Mesmo que
não haja nada escrito
nele, ele não
falha explicitamente, então está passando Então, vamos continuar e escrever
um teste real, certo? Neste momento, não estamos
preocupados em formatar nosso teste Há uma lição só para isso. Então, vou
copiar um código aqui que representa um teste de aprovação
que adiciona dois números, certo? Então, vou chamar
isso de teste de aprovação. E eu vou usar o assert. A afirmação é basicamente
verificar a igualdade. Estou verificando se
você explora isso, você tem um valor esperado
e um valor real. Então, eu espero quatro, mas meu valor real é
esse porque
é isso que estou calculando na minha classe de calculadora, certo? Portanto, para que a
classe de calculadora seja usada aqui, precisamos referenciar nosso projeto de teste de pontos
comerciais. Então, vamos clicar com
o botão direito do mouse na dependência, adicionar a referência
do projeto e clicar no ponto
comercial César, para que possamos adicionar nossa
referência de calculadora a esse Aí está. Agora você pode calcular dois mais dois e o valor esperado é
quatro se executarmos o teste. Eu passa. Você também pode
depurar, o que é muito útil Então, se eu clicar com
o botão direito do mouse no teste de aprovação, você também pode
clicar com o botão direito na classe aqui e em qualquer uma delas
e clicar em Depurar Você vê que atingiu meu ponto de ruptura, eu posso entrar
nisso o quanto eu quiser Então aqui eu tenho A mais B, ele retorna, depois
afirma e passa Então, esse teste unitário de depuração é
uma funcionalidade bastante útil Deixe-me continuar e colar mais
alguns códigos aqui. Então eu fui e colei
o teste que falhou. Então isso é basicamente
a mesma coisa, certo? Estamos adicionando dois números, mas esperamos cinco. Então, vamos seguir em frente e
falhar de propósito. Deixe-me fazer todos os testes. E como você pode ver
aqui, há um X vermelho. Então, agora meus testes estão falhando
porque um teste falha, como se todo o
namespace falhasse,
certo Então, aqui, se eu clicar
no teste que falhou, posso ver por que
ele falhou, certo? Então, você pode ver que estamos usando o assert e os
valores são diferentes O esperado era cinco, mas o valor real era quatro. Como você pode ver,
estamos tentando adicionar dois mais dois e isso falha. Então, aqui você pode explorar,
certo, ou visualizar como explorador de
testes é
muito útil, certo? Você tem o resumo do
motivo pelo qual um teste falhou. Você também tem um resumo
da aprovação no teste, como a duração, etc Portanto, essa é uma ferramenta muito útil que usaremos ao
longo do curso e é muito usada por desenvolvedores que trabalham
no Visual Studio.
11. Melhorando a redabilidade de seus testes: Olá, bem-vindo à aula sobre como melhorar a legibilidade
do teste Então, vamos analisar
a classe que foi criada quando criamos nosso
primeiro projeto de teste unitário. Quando analisamos o teste
unitário de uma classe, veremos o atributo fato. Esse atributo é usado para marcar
um método como método de teste. Isso significa que um método representa um fato que
deve ser sempre verdadeiro Um teste marcado com o atributo fato representa
um único caso de teste. Se o método de teste gerar uma exceção ou
falhar na afirmação, o teste será considerado uma
falha ou um teste com falha Bem, uma das coisas mais
importantes sobre testes é como nomear seus testes. O nome dos seus testes
quando se trata de métodos de teste deve
consistir em três partes. O nome do método
que está sendo testado, o cenário sob o qual teste ou sob o qual
ele está sendo testado e o comportamento esperado quando
o cenário está envolvido. E por que nomear seu
teste é tão importante? Os padrões de nomenclatura são
importantes porque expressam
explicitamente a
intenção do teste Os Cest são mais do que apenas
garantir que seu código funcione. Eles também fornecem documentação. Apenas examinando o
conjunto de testes unitários, você deve ser capaz de
inferir o comportamento do seu código sem nem mesmo
examinar o código em si Além disso, quando um teste falha, você pode ver exatamente
qual cenário não atende às expectativas. Também temos outro
atributo chamado teoria. O atributo da teoria é usado para definir um teste parametrizado Ele permite testar
várias entradas em relação à mesma lógica de teste Você pode fornecer uma ou
mais estruturas de dados por meio de atributos como dados
embutidos para fornecer
ao teste diferentes valores
de entrada Cada conjunto de valores de entrada é tratado como um caso de teste
separado. Se algum dos casos de teste falhar, toda
a teoria
será considerada falha. A imagem a seguir mostra um exemplo de um
atributo teórico em uso. Nós também implementaremos
isso nós mesmos. Um padrão muito comum
é o padrão AA, organizar, agir e afirmar. Esse padrão quase se tornou um padrão
em todo o setor. Isso sugere que você divida seu método de teste
em três seções, organizadas, atuem e afirmem Cada um deles
é responsável apenas pela parte
que lhes dá nome. Como a legibilidade é um
dos aspectos mais importantes
ao escrever um teste, separar cada uma dessas
ações no teste destaca
claramente
as dependências necessárias para chamar seu código, como seu código está sendo chamado e o que você está
tentando Embora seja
possível combinar algumas etapas e reduzir
o tamanho do teste, o objetivo principal é
tornar o teste o mais
legível possível Agora vamos dar uma olhada em alguns
exemplos em código. Legal. Então, aqui temos nossa solução de conjunto de
unidades, e temos nosso teste de
unidade, um com o teste de falha e o teste de
aprovação, certo? Então, a primeira coisa que
vamos fazer é
renomear nossa classe Então, vamos renomear
a classe para calculadora. Teste. O motivo pelo qual renomeamos a classe para teste de calculadora é porque a classe que está
sendo testada é chamada de calculadora,
como você pode ver aqui Então, quando temos uma classe de teste de
calculadora, isso infere que o teste de calculadora está testando a classe de calculadora de classes da
biblioteca de negócios Vá em frente e renomeie nossos testes. Só para recapitular, o nome
do teste deve conter o nome do
método que está sendo testado, o cenário em
que está sendo testado e o comportamento esperado Então, vou
renomear isso e chamá-lo de add, que é o nome do método abaixo
da linha para separar a próxima parte E digamos que deveria adicionar. Sublinhado e o
comportamento do cenário. Então, digamos que quando inteiro. Legal. Quando lemos isso, podemos ver que
estamos tentando somar, eu deveria somar e sabemos que
o número é um número inteiro Legal. Agora podemos explorar
mais alguns testes, certo? Então, vamos
copiar esses pastéis aqui. Deixe-me renomear isso para uma teoria. E deixe-me colocar
isso em um papel ruim. Vamos
adicionar alguns dados em linha. Agora que tenho os dados em linha, vou excluir
o teste que falhou. Vou criar
meu parâmetro. Então, em A, B e o esperado. Vamos
mudar isso para A,
na verdade esperado, e
estamos adicionando A e B. Então, digamos que dois mais ou
dois mais dois são quatro. Quatro mais quatro é oito e
oito mais oito é 16. Deixe-me prosseguir e também
separar isso um pouco. Vamos colocar o que esperamos
aqui para o resultado. Esta calculadora soma e depois
substituiremos isso. Agora, o resultado seria minha atuação. E essa seria minha afirmação. Então, temos A aqui, certo? Então, estamos perdendo o acordo. Vamos organizar a aula
de calculadora. Vou salvar nossa nova calculadora em vez de criar uma instância. Aí está. Organizar. Estamos
organizando uma nova instância Estamos agindo com base nos resultados
e, em seguida, afirmando o que é esperado e com base
no resultado, certo? Então, deixe-me ir em frente
e comentar esse cara. E vamos dar uma
olhada em nosso explorador de testes. E faça nossos testes. Como você pode ver aqui, existem três testes e todos
eles estão passando, certo? Temos um método que
representa três testes. Então, só para revisar
aqui, o arranjo, ele basicamente configura objetos
de teste e prepara os pré-requisitos para O ato executa o trabalho
real do teste e a declaração
verifica o resultado Portanto, isso
separa claramente o que está sendo testado das etapas de configuração
e verificação Ok.
12. Mais sobre afirmações: Oi, pessoal. Bem-vindo à
lição sobre afirmações. Então, aqui eu criei uma
classe chamada helper, e essa classe
contém um modelo G, que retorna uma nova instância do modelo auxiliar com
o nome da propriedade,
data de nascimento, saldo bancário e coleção de alimentos favoritos Como você pode ver, nosso modelo
está dentro do mesmo arquivo. Também tem um método
chamado auxiliar de processo, que dependendo do valor, ele retorna uma exceção O valor é não, retorna isso. Se o valor for um, ele retornará uma exceção não
implementada. Se o valor for dois, ele
retornará uma exceção. Então, com essa classe ou essa classe auxiliar,
isso realmente nos
ajudará a analisar
os métodos de asserção. Portanto, no teste business
dot czar dot, temos uma aula de
teste de pontos auxiliares que
vamos examinar Vamos revisar ou começar com
a afirmação booleana. Na verdade, a afirmação
booleana verifica se a afirmação
é verdadeira ou Então você tem assert dot true e você também tem assert dot false. O que isso está fazendo é,
na verdade instanciar um
novo modelo auxiliar, e então temos o saldo bancário
esperado O resultado é, na verdade,
obter um modelo. E dentro desse resultado,
temos um saldo bancário. Então, estamos verificando se o
saldo bancário é igual a 150, se o saldo bancário
é igual a 150, então isso será verdade
e isso será aprovado. Se eu executar isso, você
pode ver que passa. Se eu alterar o saldo bancário
esperado para 200 e executá-lo novamente, ele deverá falhar. E
aí está, ele falha. Legal. Então, vamos
prosseguir com a afirmação de igualdade
de strings Agora, a
afirmação
de igualdade é meio que testa a igualdade com o valor
esperado e real E esse é um dos métodos de afirmação mais
usados. A afirmação booleana poderia realmente ser substituída
por essa, e muitas vezes é ignorada, certo Já que a afirmação booleana meio que fornece mais informações sobre
por que ela falha Então, aqui temos
um nome esperado, um primeiro nome e um sobrenome esperado. Obtemos o resultado
do modelo get e estamos verificando se o nome
desse modelo é igual
ao primeiro nome, se ele começa com o primeiro nome esperado e
se termina com o sobrenome
esperado. Se eu executar isso, igualdade de cordas
, está aqui embaixo, passa. Então, se eu olhar meu modelo get, você pode ver que o
nome é Cayo Susa, e se eu olhar para o
meu nome esperado, é Kyosusa, começa
com yo e termina com SSA Então, igualdade começa e termina com são algumas de nossas afirmações de
igualdade Então, vamos seguir em
frente e passar para a próxima. Então, a próxima é a afirmação
numérica. Então, para a afirmação numérica, temos o intervalo assert.in
e também o
ponto assert que não está no intervalo, e também o
ponto assert que não está no Então, aqui estamos verificando se o saldo bancário
é de 10 a 150, certo? Então, se eu executar isso, você pode ver que passa porque
o saldo bancário é 150. Então, se olharmos para
este que falha, estamos verificando se é 10-149 E se eu clicar aqui, você pode ver que o valor não está dentro do intervalo. O intervalo é de dez a 149 e o valor real é 150 Portanto, no resumo dos detalhes do teste, isso pode realmente nos ajudar a
entender o que acontece. Então, vamos seguir em
frente e passar para a próxima. Então, a próxima é a afirmação
de referência. Então, o
tipo de afirmação de referência afirma
que, você sabe, temos
o mesmo ponto de afirmação. Há também o ponto de
afirmação que não é o mesmo. Temos o ponto de afirmação não, ponto afirmação N Vou supor que o mesmo
no nulo é o mais usado Então, o mesmo afirma que
as referências esperadas e reais
dos objetos são o mesmo objeto, certo? Então, aqui temos um resultado que
está obtendo o modelo get, e temos o modelo auxiliar, obtendo o valor do resultado Então, esses objetos
são na verdade resultado e o resultado e o modelo auxiliar
são o mesmo objeto, certo? Então, se eu executar isso, você verá
uma afirmação de referência passada. No entanto, isso pode ficar um
pouco confuso, certo? Temos a falha na
afirmação de referência. Então, aqui temos o resultado. E então eu criei
um modelo auxiliar aqui, que contém o mesmo tipo
de objeto do mesmo tipo, porém, com os mesmos valores, mas é uma nova instância Portanto, o modelo auxiliar contém
o mesmo nome de valor, mesmo valor, data de
nascimento, mesmo valor, saldo
bancário e coleção de
alimentos favoritos como resultados Então, é meio que
igual nesse sentido. No entanto, não é
o mesmo objeto pois essa é uma nova instância. Se eu tentar verificar se eles são
iguais, isso realmente falha. A afirmação de referência falha. E então, para nossa próxima afirmação, temos a afirmação de tipo Para a afirmação de tipo, às vezes
estamos verificando se o objeto é
exatamente do tipo que você espera, Então, aqui, o modelo get é,
na verdade, do tipo modelo auxiliar. Então, se eu mudar isso
para auxiliar e correr, esperaríamos uma falha aqui Aí está. Isso falha, certo? Não é do tipo exato. Se o alterarmos
ou revertermos para o modelo
auxiliar e executá-lo,
isso deve passar E aí está. Passa
porque é do mesmo tipo. O resultado é do tipo modelo auxiliar. Legal. Então, vamos seguir em frente e
passar para as coleções. Portanto, as coleções também são muito usadas em
muitos aplicativos. Então, isso pode ser muito útil. Assim, você pode afirmar se uma
coleção está vazia. Então, nossa coleção de comida favorita aqui, onde ela
realmente tem valor. Então, se eu comentar isso e
executar isso, isso deve falhar. Afirmação vazia da coleção, ela falha porque,
na verdade, há arroz ,
feijão e ovos como parte
da coleção Não está vazio. Se
eu não costumo fazer isso porque isso é meio
que forçar, certo Está forçando a coleção de alimentos
favorita
a uma coleção vazia Isso agora vai realmente
passar. Lá vamos nós. E então também
temos o não vazio. E se administrarmos a mesma coleção de alimentos
favoritos, sabemos que há arroz lá, então não vai falhar. Aí está a coleção que
contém afirmações. Portanto, isso contém,
na verdade, a verificação que um item esperado
foi encontrado nessa coleção. Então, aqui, há algumas maneiras
de fazer isso. Eu só uso um fato,
mas você pode usar a teoria ou fazer isso
de uma maneira diferente. No entanto, vamos
ver como é, certo? Então, aqui estamos verificando se a coleção de alimentos
favoritos
contém arroz, feijão ou ovos, e ovos,
neste caso, certo? Arroz, feijão
e ovos, e se
eu mudar isso para ovo, deve falhar
porque não contém ovo. Você sabe, ele contém ovos. Legal. E também, tipo, não contém, então não
contém nenhuma cenoura. Então, aqui, ele não contém e passa
porque não contém arag Para nossa última análise, veremos a afirmação da
exceção, certo? E para a afirmação de exceção, na verdade
estamos usando
o delegado de ação apenas para separar a organização do ato da Então, aqui temos o ato que, na verdade, o
delegado chama ou define
o auxiliar do processo
e, na afirmação,
ele Aqui, estamos meio que esperando aqui uma exceção nula de argumento Se observarmos o auxiliar do
processo, quando o valor é nulo,
ele lança um argumento
de exceção Dull ele lança um argumento Então, se eu executar isso, Argument
parece. Aí está. Então, se eu mudar, vamos
mudar isso para não
implementar, não implementar a exceção. Se eu alterar isso para não
implementar a exceção e
executá-la, ela falhará porque
não gera uma exceção não
implementada. Isso lança um argumento
sem exceção. Então, isso também é muito
útil e agradável.
13. Afirmações fluentes: Olá. Bem-vindo à aula
sobre afirmações fluidas. Portanto, afirmações fluentes ajudam
você a escrever afirmações em testes
unitários que sejam
simples e expressivas A biblioteca contém um
conjunto de métodos de extensão que podem ser usados para especificar o
resultado desejado de um teste unitário. Isso ajuda a afirmação a
parecer muito mais natural e também pode ser
mais fácil de compreender E também mantém seu
código limpo e simples. Você pode conferir
mais alguma documentação em fluid assertions.com 2024, havia
mais de 446 milhões de downloads da biblioteca de afirmações
fluentes InnuGet A versão dessa
data é sete,00. Essa versão pode
mudar
dependendo do tempo em que você estiver
assistindo ao vídeo. Então, vamos ver
como podemos implementar afirmação
fluente com base
em nosso último vídeo Então, em nosso último vídeo, falamos
sobre testes auxiliares, certo? Examinamos todas
ou a maioria
das afirmações
na biblioteca X Unit E neste vídeo, vamos basicamente atualizar a biblioteca ou incluir
a afirmação
fluente para afirmar. Então, a primeira coisa que você vai
fazer é clicar com o botão direito do mouse em empacotar os pacotes em sua
empresa dot czar lat test, ManageNUGT Aqui você pode clicar em Procurar
e simplesmente digitar fluente. Você verá afirmações fluentes e poderá simplesmente baixar afirmações
fluentes Como você pode ver, a versão estável
mais recente atual é 70 pontos zero. Então, aqui baixamos afirmações
fluentes
e, depois de baixá-las, você pode simplesmente
forçá-las ou usá-las Então, usando
afirmações fluentes, e pronto. Agora podemos usar
afirmações fluentes em nosso projeto. Então, vou copiar e colar
aqui apenas para acelerar
um
pouco a digitação Então, aqui, em vez de dizer
assertion dot true, vamos seguir
em frente e dizer resultado, que é o objeto que
estamos tentando afirmar E então o saldo bancário, que é essa propriedade, deve
ser o saldo bancário esperado. Então, se você comparar assert dot true result bank balance é igual ao saldo bancário esperado, result dot bank balance
should be expected bank balance
soa muito mais fluente, pelo
menos para mim, É muito mais legível
e, você sabe, muito fácil de
entender, certo? Então, se eu executar isso, você pode ver que falha porque
acho que mudamos isso
na última aula Então, se eu mudar isso para 150, aqui você pode ver que ele falha. Na verdade, ele fornece
muitos detalhes aqui, veja, 200, mas não encontrou 150 de diferença de 50,
então isso é muito bom. Se executarmos isso agora, que eu mude
para 150, ele passa. Então, deixe-me encerrar
isso. Legal. Então, vamos dar uma olhada em nossa afirmação de
igualdade fragmentada, certo? Então, aqui temos uma
espécie de três linhas aqui, e você pode realmente fazer isso Ainda é uma versão de três linhas, mas é muito mais fluente Então, aqui estamos
verificando a igualdade, começa e
termina com, certo? Então, estamos verificando o nome. Portanto, o nome do ponto resultante
deve começar com o nome
esperado e terminar com o sobrenome esperado e
conter o nome esperado. Então, muito mais fluente, muito mais legível do
meu ponto de vista E se executarmos isso,
devemos fazer um teste de aprovação para
a igualdade das cadeias. Aí está.
Igualdade de cordas, passagem. Então, vamos seguir em frente e
passar para a afirmação numérica. Portanto, na afirmação numérica,
estamos realmente verificando
o intervalo Então, aqui, muito semelhante ao resultado do teste anterior, o
saldo bancário deveria. Então, isso deve ser
como
se estivesse em todo lugar e em uma faixa de
baixa e alta faixa. Então, se eu comentar isso,
devemos ver
se isso vai funcionar. Veja, aí está, funciona. E então esse eu posso
simplesmente copiar e colar. Eu acredito que é a
mesma coisa. está falhando porque
não está dentro do intervalo Então, vamos ver o que acontece. Falha na afirmação numérica, mas encontrou 150. Sim. Então, isso é como a falha de afirmação numérica Então, vamos dar uma
olhada na próxima, que é a afirmação de
referência Então, a mesma coisa aqui. O resultado deve ser o
mesmo do modelo auxiliar. Nesse caso, ele deve falhar porque essa é uma
instância diferente do resultado. Então isso é um fracasso.
Aí está. Isso falha. E eu acredito que isso
deveria ser o mesmo. Então, este realmente
passa porque esses são os mesmos objetos. Então,
vamos dar uma olhada nisso. O resultado deve ser nulo,
veja, você pode ver, não
deve ser nulo Então eu poderia dizer: Ei, o
resultado não deve ser nulo e deve ser o mesmo que Então eu posso comentar esses dois. Meio que execute isso,
veja o que acontece. Aí está. A
afirmação de referência é aprovada Então, vamos prosseguir com nossa afirmação de tipo. Então, para a afirmação de tipo, basicamente, muito semelhante
às anteriores. Portanto, os resultados devem
ser do tipo modelo auxiliar. E esse é o
tipo que existe. E vamos seguir em frente e
olhar para o vazio. Ah. Resultado: a
coleção de alimentos favoritos deve estar vazia. E então vamos ver o que não está vazio. Portanto, não deveria ser ou a pesquisa por vazio
não deve estar vazia. Aí está. Não estar vazio,
não deveria estar vazio. Então, estão saindo esses caras. E vamos rodar esse. Então, este não está vazio. E depois há essa
que está vazia. Aí está. Ambos passam. E então temos a coleção contida. Então, este é um
pouco diferente porque este
realmente usa uma lista. Portanto, isso simplifica muito. Então, em vez de usar variáveis,
ele usa apenas uma lista. Então, aqui temos essa
lista dentro de uma coleção dentro da variável
esperada. Não precisamos de
vários contêineres. Agora podemos simplesmente usar o contenção. Então, aqui eu posso comentar isso
e eu poderia simplesmente executar isso. Estou verificando se a coleção de alimentos da
tarifa contém a lista esperada. E, como você pode ver, passa. Então, vamos seguir em frente e passar para o Então, este está contido. O outro
simplesmente não está contido. Então, basicamente, a mesma coisa aqui, os resultados devem ser como se não fossem
contidos. Não contido. E aí está onde está? A coleção não
contém afirmações. A coleção não
contém asserção
e, para nossa última,
é o Argumento nulo Então, para o argumento não
, basicamente Act should
throw argument null exception Faz. E aí está nossa
biblioteca de asserções fluente implementada.
14. Cobertura de código e dicas: Olá. Bem-vindo à
aula sobre cobertura de frio e dicas. Então, vamos recapitular O que é cobertura de código? Em engenharia de software, a cobertura de
código, também chamada de cobertura de teste, é uma medida percentual
do grau em que o código-fonte de um programa é executado quando uma suíte de
testes específica é executada. Muitos desenvolvedores dizem que a cobertura de
código não é muito útil quando se trata de
testes, o que importa, certo? Então, talvez se você quiser testar a lógica de negócios, etc No entanto, a
cobertura de código não deve ser usada como uma meta percentual. As ferramentas de cobertura de código devem
ser usadas para permitir que os desenvolvedores entendam quais partes não
são cobertas e por quê. Então, primeiro, temos a cobertura da
linha, certo? Portanto, desenvolvedores que pretendem obter cobertura de
linha em
pelo menos um caso de teste que cubra a linha em teste. Não importa se essa linha contém uma declaração
if complexa para, você sabe, cheia de condições. Se um teste tocar
nessa linha de alguma forma, o desenvolvedor pode contar
essa linha como coberta Também temos cobertura de filiais, que leva em consideração
o fato de que, você sabe, as instruções de ramificação,
como os ses, os quatros, os contras e assim por diante. Então, isso faz com que o
programa, você sabe, essas instruções façam
com que o programa se comporte de
maneiras diferentes, dependendo como a instrução
é avaliada. Por exemplo, se a afirmação A, if, você poderia
ter A e B, A ou B, ter pelo menos um caso de teste para a condição verdadeira e falsa é suficiente para considerar que
o galho está coberto. E também temos a extensão de cobertura do
Fine code. Portanto, essa extensão oferece suporte a projetos centrais.net e
projetos.net framework.NET E é uma extensão
que você pode usar na edição comunitária do Visual
Studio. É gratuito e
nos ajuda a entender e avaliar a cobertura
de código do nosso aplicativo. Então, vamos dar uma
olhada no código
da lição anterior
e ver como podemos usar fina do código para
medir a cobertura do código. Então, aqui temos o projeto
ou a solução de teste unitário. Então, a primeira coisa
que você quer fazer é
instalar uma cobertura de código fino. Para isso, você clicará
em extensões, gerenciará extensões e, em
seguida, procurará uma boa cobertura de código. Há uma boa cobertura de código. Nesse caso, ele
já está instalado, mas basta
clicar em Instalar. Vou clicar neste
Color TweakERP aqui. Você vê que há um botão de
instalação. Portanto, se você não o
tiver instalado, deve
haver um botão de
instalação e ele meio que o
instala para você Aqui temos uma captura
de tela de sua aparência, certo? Então, vamos seguir em frente
e executar essa ferramenta. Então, para executar a ferramenta, você vai clicar em Exibir. Verifique se há outras janelas
e, em seguida, você deverá ver a cobertura do código
fino aqui. Então, para realmente ter
essa saída aqui, temos que executar nossos testes. Então, vamos prosseguir
e fazer nossos testes. 13 passes para falhar. Os dois que estão
falhando são aqueles que
esperávamos que falhassem Mas vamos ver o que
estamos tentando procurar aqui. Então, em nosso código-fonte, temos o modelo auxiliar Temos o ajudante e
temos a classe de calculadora. E então você pode
ver que há
100% de cobertura da classe de
calculadora. Há 70,5% de cobertura
da classe auxiliar e 100% de cobertura
de linha do modelo Estamos perdendo testes
dentro do ajudante. Se olharmos para a classe
auxiliar aqui, deixe-me revelar um pouco Podemos ver que é
vermelho aqui, sabe? Veja, eles não foram testados. Então é por isso que há 70%. E o que está em verde
é o que foi testado. Então aqui, há, tipo, um amarelo porque é uma cobertura de
ramal, e o vermelho indica
que não foi testado Então eu posso
ver, ok, essas são as linhas que eu
preciso testar, certo? Essas são as linhas
que estão faltando, e essa é uma ramificação que
eu talvez queira considerar. É uma ferramenta muito boa. Isso ajuda você a
entender, você sabe, o que foi coberto e
o que não foi coberto. Você sabe, você pode
verificar os resultados. Você pode verificar a filial, verificar a cobertura da linha, verificar as porcentagens, e é uma ferramenta realmente incrível.
Então, aí está a cobertura. Há um resumo, há alguns pontos críticos, se você quiser ver alguns como complexidade
ciclomática aqui
e alguns complexidade
ciclomática aqui
e alguns E é basicamente isso.
15. Teste de unidade com xUnit Review: Olá. Bem-vindo à aula sobre testes unitários
com o X Unit Review. Então, agora que escrevemos
nosso primeiro teste unitário, exploramos a biblioteca de unidades X. Quero
incentivá-lo a escrever
um software que simule a operação de uma
calculadora Dentro do software,
queremos ter certeza de que temos as operações básicas, como
adicionar, dividir e multiplicar Você deve escrever testes de unidade que abranjam todas as funcionalidades, casos de
aprovação e falha Depois disso, certifique-se
de executar uma ferramenta de cobertura de código para
poder medir a cobertura
de código da sua base de código. Então eu incentivo você a
publicar seus resultados no GitHub. Então, vamos resumir esta seção. Começamos com os
primeiros passos com o X Unit. Eu explico por que o Xnit é
uma biblioteca tão importante. Criamos um projeto de teste
e exploramos o Visual Studio. Escrevemos nosso primeiro teste unitário. Visualizamos o teste unitário usando o Test Explorer e o executamos
por meio do Test Explorer. Formatamos nossos testes
usando o padrão thea, que é um padrão muito usado Também analisamos a
cobertura de frio e algumas dicas básicas. Nesta lição,
você deve ser capaz de
escrever confortavelmente testes unitários, executar cobertura a frio e ter formatação básica
para seus
16. Requisitos de números de segurança social: Olá. Bem-vindo à aula sobre os requisitos de
números do Seguro Social. Então, vamos falar sobre os requisitos
de software. Os requisitos de software são
um artefato muito valioso quando se trata de testes de
software Os requisitos contêm os recursos ou restrições não
funcionais que o software
deve fornecer para
atender às necessidades dos usuários
e de outras Os requisitos nos dizem
exatamente o que o software precisa fazer e o
que não deve fazer. Eles descrevem as complexidades das regras de negócios
que o software deve implementar e como
elas devem ser Portanto,
os requisitos devem ser o primeiro artefato que
os desenvolvedores devem levar em consideração quando se
trata de testes Construiremos um
traje de teste usando o X Unit no Visual Studio com base
nos requisitos fornecidos. Vamos criar
um aplicativo que
insere um usuário em um banco de Vamos usar
os seguintes dados, o nome
do usuário, o sobrenome
do usuário, a data de nascimento do
usuário e o número do
Seguro Social do usuário. Usuários entre
dez e 80 anos são permitidos
no sistema
e o número do Seguro Social deve ser válido. Na parte sobre o banco de dados, não
vamos implementar
a inserção real, mas implementaremos o que
seria uma simulação de uma inserção do banco
de E você verá isso
quando começarmos a programar. Para os requisitos do
número do Seguro Social, esses são os requisitos. Primeiro, o número do
Seguro Social deve seguir o
seguinte formato. A primeira parte é
chamada de número da área. A segunda parte é
chamada de número do grupo e a última parte é
chamada de número de série. O número da área contém
três dígitos e não pode ser 000666 O número do grupo pode não ser 00 e também é um número de
dois dígitos,
e o número de série é
um número de quatro dígitos
e pode não ser Legal. Vamos dar uma olhada em alguns códigos. A primeira coisa que fiz
aqui foi criar uma pasta de número de previdência social na classe business dot cesar Para isso, você pode
clicar com o botão direito do mouse no projeto, clicar em Adicionar e depois em Nova pasta
e, em seguida, nomear essa
pasta como quiser. No meu caso, eu o chamei de SSN, que significa número do
Seguro Social Agora vamos clicar na pasta,
clicar em AD e adicionar uma nova turma. Vou nomear
esse usuário da classe. Certo, agora vou
criar um modelo para o usuário, então vou
torná-lo público e vou criar
algumas propriedades. Então, primeiro, vou
criar o primeiro nome. Vamos ter o sobrenome. Vamos ter a data e a data de nascimento.HOME. E vamos em frente e ter
o número do Seguro Social. Portanto, temos o primeiro nome
String, o sobrenome String, data de nascimento, como data/hora e o
número do Seguro Social como string Legal. Então essa é a nossa entidade
de usuário com a qual
trabalharemos. Agora vou criar
uma classe de dados do usuário, que é responsável por inserir o usuário
no banco de dados Então, vamos criar
uma classe chamada dados do usuário. Vou criar, tornar público
, tornar
tudo público. Então, vamos nomear ou criar um método
chamado insert user. Então, vazio público. Insira o usuário. Eu estava alterando minhas configurações de
palavras-chave. Tudo bem, então public
void insira o usuário, e o parâmetro disso
é na verdade o usuário Legal. Portanto, temos um usuário
como parâmetro e não nos
importamos muito com o banco de dados, então vou dizer que
descarte a exceção de implementação. Estamos simulando uma inserção, mas realmente não nos
importamos com o Lembre-se de que, nos testes unitários, não
nos importamos com
integrações. Então, um banco de dados é uma integração
com um sistema externo, certo, que contém dados, e nós realmente não nos
importamos com isso. No entanto, precisamos
desse método porque simularemos uma
inserção no banco de dados Então, estamos zombando disso, certo? Então, falaremos
sobre isso nas próximas aulas, mas vamos continuar
assim por enquanto. Portanto, temos os dados do usuário. E por último, mas não menos importante, vamos criar uma classe de número do
Seguro Social. Então, vou criar
uma nova classe e chamá-la de número do Seguro Social. Eu também vou
tê-lo como público. Legal. E vou criar um
método chamado insert user. Então, anular o público, insira o usuário. Se estivéssemos desenvolvendo isso e algum tipo de arquitetura
estruturada, poderíamos ter essas classes
em uma camada diferente. Mas neste momento,
eu gostaria de manter as coisas simples, certo? Portanto, temos um método
para inserir o usuário. Também vou criar um
método de tableanPublic bowl e vou chamá-lo SSN
válido ou número do
Seguro Social,
que basicamente está validando o número do Então,
número do seguro social, certo? Por enquanto, vou fazer com que isso retorne falso. E vamos em frente e
perdemos um Aí está. Vamos seguir em frente e
implementar esse método. Então, ou está faltando o usuário aqui. Portanto, o usuário inserido
usa o modelo do usuário. Portanto, se o número do Seguro
Social ou, se não for válido , ou se o
número do Seguro Social não for válido, lançaremos uma nova exceção. Digamos que uma
exceção de dados é inválida e vou tentar me
acostumar com esse teclado Tudo bem. Tão legal. Temos uma exceção de dados inválidos, então vou apenas dizer SSN
inválido aqui. Certo. Legal. Agora vamos
instanciar um novo dado do usuário, que é meu método de dados
responsável por inserir um usuário no banco de dados apenas
para seguir Então, se o número do Seguro Social for válido, eu quero inserir. Então, vou
continuar e dizer:
Ei, insira meu usuário
no banco de dados. Agora eu tenho uma espécie
de esqueleto
do aplicativo em que
tenho minha entidade Modelo. Eu tenho meu modelo de dados e minha lógica de negócios, onde implemento
a validação e a inserção
do, você sabe, usuário Então, dentro disso ou
com esse esqueleto, vamos implementar
todos os nossos testes unitários E, é claro, vamos
realmente implementar as validações
reais e você verá isso nas próximas aulas,
à medida que implementarmos e testarmos
nossos requisitos
17. Acesso de dados simulados com MOQ: Olá, bem-vindo à aula sobre simulação
do acesso a
dados com o MC Portanto, neste momento,
não nos importamos realmente inserir o usuário no banco de
dados real Nós nos preocupamos em testar as regras de número do Seguro
Social. Mesmo que a implementação
dos dados do usuário
estivesse pronta e
tivéssemos um banco de dados pronto para ser usado
no nível de teste unitário, não
nos importamos em nos
conectar a um banco de dados. Lembre-se de que isso não é um teste de
integração. Portanto, a solução aqui é,
na verdade, simular os dados de um usuário. E para fazer isso, precisamos criar dados ou
criar
uma interface de dados do usuário e , em seguida, injetar essa interface
no código E vamos ver
isso dentro do código. Hum, então temos o pacote MQ ou
pacote simulado, MQ. É uma biblioteca popular
para zombar em.net. Atualmente, está na versão 4.272 e há mais de
730 Para recapitular, um objeto simulado é criado para simular
o comportamento de um objeto real a fim de testar
a funcionalidade de outros componentes de software
que dependem dele Então, no nosso caso,
queremos simular a inserção
do usuário
no banco de dados, certo inserção
do usuário
no banco de dados, Hum, aqui temos a aparência do nosso contrato
de dados do usuário, então vamos basicamente
criar uma interface chamada I user data, e então vamos
usar
essa interface e
injetá-la em nosso código Então, também vamos usar
o automok apenas para facilitar a injeção de
dependência,
a resolução da injeção de
dependência, e isso vai um
pouco mais fundo, mas basicamente
automatiza nossa simulação Então, atualmente o Automoc tem
15 milhões de downloads. É uma espécie de
contêiner simulado para M, e isso realmente ajuda se
você investe em,
tipo, inversão de controle e quer desacoplar
seu teste unitário,
você sabe, mudanças nos Então, vamos dar uma
olhada em alguns códigos aqui. Então, aqui nos dados do usuário, se você clicar nos
dados do usuário e clicar no ponto de
controle e
extrair a interface, isso basicamente criará uma interface chamada I dados do usuário. Para nós, ele automatiza
a criação da interface
e, em seguida, podemos usar ou injetar os dados do usuário eletrônico dentro do número
do Seguro Social Então, vou seguir em frente
e criar um construtor. Aqui, vou criar
uma variável privada. Eu vou injetar
isso. Aí está. Dados do usuário e, em seguida, vou
usar esses dados do usuário como meu contrato aqui, em vez de
instanciar uma nova classe Então, aqui e agora eu
tenho um contrato, você sabe, interface de dados do usuário. E também, agora minha
estrutura está acoplada, em certo sentido, não acoplada, mas, você sabe, ela tem essa
dependência Então, o Automa meio que nos ajuda a
resolver essa dependência. Isso
resolve isso magicamente para nós. Então, vamos
fechar tudo isso, salvar, fechar e dar olhada no nosso teste. Aqui, estamos tentando testar a classe de
números
do Seguro Social. Vamos clicar com o botão direito do mouse no projeto, clicar em AD e adicionar um teste de número do Seguro
Social basicamente
ao projeto de teste. Deixe-me renomear isso para teste de número
de previdência social. Temos o teste do número do
Seguro Social. Então, deixe-me copiar alguns códigos aqui apenas para fins de
produtividade. Então, aqui temos o Auto Marker. Então, vou clicar em
pacotes Adicionar pacote Nugget. Vou pesquisar o Mc e
vou adicionar o M ou instalar
a biblioteca Mc. Atualmente na versão
four dot 20. O tipo de limpar
todos esses testes. Eu também vou
adicionar o Mu automoc. Portanto, instale
essas duas bibliotecas. Essas são as bibliotecas que
vamos usar. Legal. Então, temos o MQ,
temos o Mach Então, se voltarmos ao nosso teste e eu meio que quiser
controlar isso aqui, você pode ver esse tipo
de, Ei, use um carro Então, aqui está usando o Automoc agora. E na construção do
teste de número
do Seguro Social, instanciando,
você sabe, ou mantendo
esse objeto, espécie de direito global
ao marcador automático Então, eu tenho que recriar isso toda vez ou para cada método Então, aqui eu tenho meus automarkers,
uma variável global, e vou criar
um método chamado Inserir um método chamado Inserir Então, eu tenho esse método aqui. usuário chamado insert não deve gerar uma exceção
quando o usuário é inserido. Então, agora eu quero saber, quero ter certeza de que isso não
gerará uma exceção, certo? Portanto, lembre-se de que, ao
chamar os dados do usuário, isso realmente gera uma exceção Se eu for para a implementação
, estou forçando a exceção Queremos ter certeza de que essa exceção não
será lançada. Então, primeiro, vamos
criar um
método privado chamado criar usuário, e isso vai nos ajudar
a criar e isso vai nos ajudar
a criar usuários com um número de
previdência social. Portanto, esse método retorna um usuário. Tem como parâmetro o número
do Seguro Social, apenas retorna um objeto
com o nome,
sobrenome, data de nascimento e o número do
Seguro Social fornecido. Então, é
como um criador para nós. Então, isso vai criar
esse objeto para nós, e eu vou usar isso para organizar e configurar nossa simulação Então, vamos dar uma olhada em nossa variedade aqui. Não esse, é
esse aqui. Vamos dar uma olhada nesse arranjo aqui. Dessa forma,
temos o usuário com rede social
válida que criamos
com o método create user. Isso é apenas
criar um usuário com
um número de
previdência social válido, onde seguida,
instanciamos uma instância do
número do Seguro Social usando nosso MAC automático Objeto. Então, isso cria uma instância e resolve a
dependência para nós E então nós meio que
configuramos nossa simulação automática. Então esse é o nosso M, certo? Então, toda vez que os
dados de um usuário são chamados, queremos ter certeza de
que isso não gerará
uma exceção, certo? Portanto, queremos ter certeza de
que, quando isso for chamado, simulemos
o usuário de inserção
desse usuário com uma rede social válida Então, isso
evitará a simulação. Isso evitará que uma exceção seja lançada, porque
na verdade não vamos chamar esse método Vamos simular o método de
resposta do usuário. Então, agora podemos agir, certo? Então, lembre-se de que
estamos testando para garantir que
não lançaremos uma exceção, então vamos
usar um delegado aqui Então, para isso, vamos agir ou chamar o usuário da resposta
como delegado aqui, e isso vai
nos ajudar a testar as exceções, como vimos anteriormente
na E para a
afirmação, basicamente, queremos apenas
garantir que ela
não gere uma exceção, certo? Então, vamos seguir em frente
e fazer esse teste. E isso falha. Está gerando
uma exceção invalidada Vejamos nosso método de
inserção de usuário e, na verdade, ele está retornando um número inválido do
Seguro Social Vou forçar isso a ser
verdade para que possamos passar por
essa validação. Obviamente,
vamos implementar
o código para validar o número do Seguro
Social Neste momento, vou apenas
garantir que meu teste passe. Vou forçar
isso a ser verdade por enquanto, vamos continuar e refazer isso
e devemos atingir esse ponto de interrupção aqui Então deu certo, chamou esse método e
atingiu tudo isso, e isso está marcado. Isso foi ignorado e eu simulei com sucesso o
usuário de inserção de pontos de dados do usuário, que é basicamente o que eu estava procurando
nesta lição Simulamos isso com sucesso
e, na próxima lição, implementaremos parte de
nossa lógica de negócios
18. Testando os requisitos por unidade parte 1: Olá. Bem-vindo à lição sobre testes unitários
dos requisitos, parte um. Nesta lição,
examinaremos os requisitos e
implementaremos a validação de idade. Então, implementamos
o aplicativo que insere um usuário
em um banco de dados e também implementamos o modelo que
inserimos no banco de dados Portanto, temos o
nome, o sobrenome, a data de nascimento e o número do Seguro Social
do usuário. Nesta lição, vamos
prosseguir e implementar a validação da
idade desse usuário. Portanto, usuários entre dez e 80 anos são permitidos
no sistema. Então, vamos dar uma
olhada em alguns códigos. Então, aqui temos
nossa base de código com nosso teste de unidade e
o usuário de criação. Então, a primeira coisa que vou
fazer é criar um novo teste para realmente tentar inserir um usuário com menos de dez anos. Então, vou seguir em frente
e colar esse teste. Venha aqui para que possamos
analisar isso rapidamente. Então, aqui temos um método
chamado insert user, e ele deve lançar uma exceção quando a idade for menor que dez anos. Lembre-se de que a faixa
etária deve ser maior que dez anos. Então, na seção organizada, eu implementei uma variável que recebe uma data que está a um
dia de ser dez, certo? Então você tem 10 anos mais um, isso significa que você tem nove dias
e um dia a partir dos Em seguida, criaremos
um usuário com base nessa data. Deixe-me seguir em frente
e basear o código para criar o usuário
com base na data. Esse código aqui cria um usuário
com base na data de nascimento. mesmo que este, este cria com base no número
do Seguro Social, como você pode ver
aqui, e este
cria um usuário com
base na data de nascimento. Legal. Então, criamos um usuário
aqui com uma idade inválida. Criamos nossa instância Mc
em nosso mooc de dados do usuário. Deixe-me prosseguir e atualizar
isso para inserir o usuário. E então, basicamente, estamos
afirmando que isso deve gerar uma exceção de
dados inválida Então, deixe-me fazer esse teste e vamos ver o que acontece. Legal. Como esperado, o teste
falhou porque não implementamos a lógica
para a validação da idade. Então, vamos dar uma
olhada na base de código, certo? Então, vamos dar uma
olhada na classe de
números do Seguro Social. Então, esse tipo de
implementação é algo usado no TDD, certo, desenvolvimento orientado a
testes, onde
você primeiro escreve seu teste, eles falham e depois você
escreve o código para corrigi-lo É muito útil porque
o teste está, na verdade validando o que estamos
procurando, certo? Estamos procurando uma exceção quando a idade é
menor que dez anos. E
ainda não implementamos, então isso meio que nos alerta:
Ei, você tem que implementar
isso antes de seguir em frente. Portanto, é uma
maneira muito boa de se desenvolver. Então, vamos em frente e vamos
implementar a validação de idade. Então, vou continuar
e colar alguns códigos,
novamente, apenas para fins de
produtividade. E então podemos
revisar o código. Portanto, este é um validador de idade. É basicamente uma tigela
que, você sabe, retorna se a idade for
válida, se for verdadeira ou não. Aqui, há um método chamado get age, onde obtemos a idade. Então, isso calcula a idade
com base na data de nascimento. E então, se a idade
for menor que igual a 80 ou maior
ou igual a dez, retorno é verdadeiro, certo? Portanto, tem que ter de 10 a 80 anos. E agora podemos usar essa idade
válida em nossa base de
código, certo? Então eu posso usar isso. Na verdade, posso ter
uma declaração IF aqui. É uma idade válida e podemos obter a
data de nascimento. Se não for válido ou
se a idade não for válida, podemos lançar uma exceção de dados
inválidos E digamos que idade é
inválida. Legal. Então, agora temos nossa validação
de idade. Então, vamos continuar e
fazer esse teste novamente. E aí está. A
validação da idade foi aprovada, certo? Então, implementamos nossa lógica, implementamos nosso teste unitário e validamos a idade de
menos de 10 anos E agora eu encorajo você
a escrever um teste unitário para validar a idade
diferente de 80, certo? Assim, podemos cumprir as regras
de negócios.
19. Testando os requisitos por unidade parte 2: Olá. Bem-vindo à segunda parte da lição sobre testes unitários
dos requisitos. Então, vamos analisar
os requisitos. Primeiro, criamos um aplicativo que insere um usuário
em um banco de dados Em seguida, inserimos os
seguintes dados, nome, sobrenome, data de nascimento e número do Seguro Social do usuário. Validamos a idade, que é menor que dez anos, e depois vamos passar
para número do
Seguro Social Portanto, um
número do Seguro Social deve ser válido. Para isso, temos as
seguintes regras, certo? O
número de segurança de origem tem o formato de
um número de três dígitos, número de dois dígitos,
número de quatro dígitos A primeira parte é
chamada de número da área. A segunda parte é
chamada de número do grupo e a última parte é
chamada de número de série. O número da área não pode ser
000-66-6999 ou 900 ou 999. O número do grupo
pode não ser 00 e o número de série
pode não ser 0000 Então, vamos dar uma
olhada em alguns códigos. Então, vamos
seguir uma abordagem de TDD
e, primeiro, escrever o teste unitário e depois
implementar nossa validação Então, para fins de produtividade ,
vou pagar alguns códigos e
vamos revisar esse código. Então eu criei uma teoria
que testa a área. Estou testando uma área que
começa com 000666 900 ou 999. E basicamente, o nome
do método ou sim, o nome do método é o nome
do método em
teste e, em seguida, o que você sabe,
deve lançar uma exceção. Portanto, esperamos uma exceção
quando a área for inválida. Então, aqui temos que criar um número de Seguro Social com
base nos parâmetros de dados embutidos Então, tudo isso é inválido. Temos o Mc para a classe executiva do
número do Seguro Social
e, em seguida, temos o Mc
para os dados do usuário ocular. Vou prosseguir e
corrigir esse usuário de inserção, e chamamos nossa ação e
esperamos uma exceção Então, se eu executar este
teste de unidade , deixe-me expandir. Isso não gera uma exceção. Na verdade, gera uma
exceção. Vamos dar uma olhada nisso. Então, na verdade, está
gerando uma exceção. Vamos dar uma olhada em nosso usuário criado com base na data de nascimento ou, na verdade, no número do Seguro
Social. Portanto, a data de nascimento
é a hora da data atual. Isso significa que o usuário
tem menos de dez anos. Então, vamos resolver isso. Deixe-me dizer que adicione anos -11 Vamos continuar e fazer isso de
novo. E aí está. Agora, não está gerando uma
exceção conforme o esperado, porque a área não está sendo validada em
nossa lógica de negócios Então, vamos dar
uma olhada na área aqui. Então, quando acessamos o número válido do Seguro
Social, podemos ver que ainda não
temos nenhuma implementação. Então, a primeira coisa que vamos fazer é implementar a
lógica para a área. Então, deixe-me
pagar um código. Então, a primeira coisa que
fizemos aqui foi pegar os primeiros três dígitos do número do Seguro Social Então, estamos obtendo os
primeiros três dígitos, que representam a área E se a área for 000666
900 ou 999, retornaremos false. E, basicamente, isso é
validar a área, certo? Então, agora temos a validação da
área. Vamos voltar ao nosso teste de
unidade e executar isso. E aí está. Nenhuma
exceção foi lançada Na verdade, exceções foram lançadas e o teste foi aprovado, certo? Portanto, esperamos que uma exceção
seja lançada porque se o
número de segurança de origem for inválido, ele lançará uma exceção
invalidada Legal. Então, vamos seguir em frente
e passar para o nosso grupo. Então, vamos criar o
teste unitário para nosso grupo. Então, para isso, vou
rolar para baixo até
aqui para fechar isso. Então, desça até aqui e
crie esse método. Portanto, este é chamado inserção. O usuário deve lançar uma
exceção quando um grupo é inválido Portanto, um grupo inválido não pode
conter o dígito 00. Nesse caso,
vou atualizar isso, inserir o usuário e Walla,
aí está Então, deixe-me executar isso, e isso
não é para que não gere uma exceção porque
na verdade não estávamos validando o grupo,
então ele falhou, certo? Esperamos uma exceção, mas ela não
gerou uma exceção Então, vamos voltar à validação
do
número do seguro social e implementar a lógica da validação
de grupo, que é muito semelhante aqui. Então, vamos obter a
substring para o grupo. Então está entre,
começa no índice quatro e tem o comprimento de dois. Então, esse tipo de
string obtém a substring do grupo
e, se for 00, retorna false Eu posso simplesmente clicar aqui
e fazer meu teste. E aí está. Uma exceção é lançada, então o teste é aprovado. E por último, mas não menos importante, vamos
implementar nosso teste de unidade para a validação do
número de série. Muito parecido com
os anteriores. Então, deixe-me minimizar isso. usuário inserido deve lançar uma exceção quando o número serial for
inválido Deixe-me corrigir isso. Inserir usuário. Então,
aqui estamos procurando um número de série que
seja igual a 0000 Se for esse o caso, ele
deve lançar uma exceção. Portanto, esperaríamos uma exceção. Se eu executar esse
teste de unidade, ele deve falhar. Ele falha porque ainda não
implementamos isso. E se voltarmos
à implementação, podemos seguir em frente e simplesmente
implementar essa parte. Então, aqui vou
criar a seção serial. Vamos pegar os
últimos três dígitos. E se esses últimos três dígitos iguais a zero, zero, zero
, retornaremos false, e isso gerará uma
exceção aqui Então, se eu voltar a executar este
teste, aí está. Implementamos
nossa lógica de teste com base em cenários de falha. Obviamente, você pode explorar cenários
positivos e fracassados. Eu sempre gosto de começar com
os cenários de falha, mas aqui você pode
explorar ainda mais Com esse tipo de
teste unitário com esse tipo
de implementação, é muito mais seguro
fazer alterações, certo? Eu posso facilmente
fazer alterações na lógica de negócios. E execute meu NICS para
garantir que, você sabe, todas as validações
baseadas em meus requisitos sejam atendidas Então, você sabe, isso dá aos
desenvolvedores, você sabe, dá aos engenheiros de software
uma sensação de segurança. Você sabe, você pode
evoluir seu software. Você pode trabalhar com seu
software e garantir que, você sabe, a funcionalidade básica os requisitos
básicos
sejam atendidos.
20. Testando os requisitos por unidade parte 3: Oi, pessoal. Bem-vindo à lição sobre testes unitários
dos requisitos P três. Por isso, implementamos nosso
grupo de áreas e a validação zero. No entanto, ainda falta uma validação para o número do Seguro
Social. Ainda não testamos unicamente o formato do número do Seguro
Social. Então, vamos seguir em frente
e implementar isso. Deixe-me copiar este porque
vamos usar a teoria e vou colá-lo aqui. Eu vou dizer que o usuário Insert deve lançar uma exceção
quando o formato for inválido Legal. E
deixe-me testar alguns formatos
inválidos Então eu vou
dizer AAA um, dois. Portanto, esse é um
formato inválido. Vamos ver aqui. Um, dois, três,
em vez de um
traço, vou colocar um número,
para não ter os traços Vamos pensar aqui. Vamos ter null null
como formato válido. Vamos também ter um vazio. E vamos fazer isso para ver o que
acontece, certo? Portanto, não implementamos
nenhuma validação de formato. Vamos ver se uma exceção não foi lançada para nenhum deles, então, você sabe, já
temos alguns erros. Então, vamos executar isso para que uma exceção não seja
lançada para este, e para o
parece ser nulo, certo? Então, dois dos nossos casos de teste falharam. Basicamente,
esperamos uma exceção para todos esses formatos
inválidos E provavelmente há muito mais formatos inválidos
que, você sabe, se pararmos para pensar ou,
você sabe, pensar sobre isso, provavelmente
há muito mais que você pode inserir ou
ter aqui E isso é muito bom, certo? Você tem um método que está validando quatro formatos
inválidos Então, vamos seguir em frente e
implementar nossa lógica de formato. Então, vamos ver o número do Seguro
Social válido, e a primeira coisa que vamos
fazer é validar o formato Então, vou colar esse código aqui para que
possamos examiná-lo. E aqui vamos usar
uma biblioteca chamada Regex, que é uma biblioteca que nos ajuda a validar formatos com base em expressões
regulares, certo Então, aqui estamos verificando
se há uma correspondência em que o número do Seguro Social
tem um número de três dígitos, depois há um traço e eu espero
um número de dois E depois outro
traço e, em seguida,
espero um número de quatro dígitos Então, basicamente, isso é uma validação para o número do Seguro
Social Precisamos de três números, dois
números, quatro números. Se for uma letra ou
outra coisa, se não for um número,
se não houver um traço,
a validação deverá falhar Então, deixe-me ir em frente e
fazer esse teste novamente. E aí está. Todos esses dados
aqui são inválidos e nosso teste de unidade validou que todas essas entradas são geradas em uma
exceção Então, estamos esperando uma exceção, como você pode ver aqui, e todas elas agora são consideradas
exceções Então,
validamos o formato com sucesso.
21. Cobertura de código: Oi, pessoal. Bem-vindo à
aula sobre cobertura de código. Então, vamos analisar
nossa cobertura de código para implementação dos requisitos da Previdência
Social. Então, a primeira coisa que
vamos fazer é clicar em Exibir outras janelas e , em seguida, pesquisar uma cobertura de código
fino. Vou prosseguir e
clicar na guia Teste,
clicar em Test Explorer. Vou filtrar classes de teste
do
número do Seguro Social e vou fazer todos os meus testes para o número do Seguro Social. E agora temos nossa
cobertura de código fino para essas classes. Vamos analisar a classe de números do
Seguro Social aqui. Aqui temos 97,2% de cobertura de linha
e 88,4% de cobertura de código. Se abrirmos a aula aqui, talvez
possamos
ver alguns resultados. Aqui estamos cobrindo
todas essas linhas, estamos cobrindo todas essas linhas. Para a validação de idade, estamos perdendo a validação de idade maior que 80 ou
maior ou igual a 80, certo? Então lembre-se, essa é a parte do galho que está faltando. E depois também envelhecem. Mesmo sendo um
método privado, ainda falta,
você sabe, a idade,
que, para ser sincera, pode não ser tão importante. No entanto, lembre-se a cobertura de
código nos ajuda a analisar
o que perdemos, certo? Então, digamos que você esteja implementando
sua lógica de negócios. Você entende que
perdeu isso, mas considera que isso não é tão importante, certo? Talvez o mais importante seja sua lógica comercial real, que é seu número de série,
seu grupo, sua validação de
área, claro, sua
validação de idade é importante. Queremos ter certeza de que
cobrimos tudo isso. Então, isso pode ser um
dever de casa se você quiser,
você sabe, explorar, implementar
e obter 100% de teste unitário Acho que essa seria uma
ótima oportunidade para e também validar
que
a idade
superior a 80 anos é outra
coisa que você poderia fazer e, com sorte, obter 100% se isso fosse algo
que você desejaria Então, o valor real
aqui é que, você sabe, como mencionei anteriormente, é validar suas regras de
negócios, certo? Implementamos
um aplicativo, um aplicativo muito simples que não tem acesso
ao banco de dados, mas simulamos
as operações e inserções do banco de dados Implementamos nossas regras comerciais para o número do Seguro
Social e conseguimos validar a maioria de nossas regras comerciais Validamos a maior parte de
nossas regras de negócios. Isso dá, você sabe, engenheiros
de software
mais segurança. Isso nos dá, você sabe, poder para fazer mudanças ou
segurança para fazer mudanças, certo? Podemos fazer alterações
e, de certa forma, garantir que nossas regras de
negócios nossa lógica sejam cumpridas
quando você refatora, atualiza sua
base de código e faz alterações Esse é um aplicativo bem
simples,
porém, os testes unitários
são pequenos, certo? Então, quando você chega
ao mundo real, você ainda está escrevendo
pequenos métodos. Você ainda está escrevendo,
sabe, ainda está
validando sua lógica Embora seja
simples, isso é muito aplicável a cenários
do mundo real. Espero que isso, analisando
a cobertura do código, implementando o teste unitário,
revisando os requisitos, abra seus olhos para o
valor do teste unitário O objetivo aqui é
garantir que você, como engenheiro de
software, entenda o valor
dos testes unitários,
como eles podem ajudá-lo a
evoluir como desenvolvedor, ajudá-lo a evoluir sua base de
código, Escreva um código melhor, escreva métodos concisos
menores e
valide esses métodos, valide suas regras,
onde você pode ter um software
que possa evoluir,
até obter uma
arquitetura melhor ou atender a
quaisquer
requisitos comerciais ou
à quaisquer
requisitos comerciais ou meta de seu produto
22. Conclusão do curso: Oi, aí. Bem-vindo à conclusão
do curso. Em primeiro lugar, se você está
assistindo a este vídeo, gostaria de
parabenizá-lo por ter chegado até aqui Eu diria que 90% dos
profissionais não investem o tempo que poderiam
ou com certeza em aprender, e você faz parte dos 10%. Índice Nesta seção, abordaremos os principais tópicos ensinados ao longo do curso. Então, vamos dar uma visão geral. Primeiro, examinamos os fundamentos do
teste de software Falamos sobre por que o
teste de software é importante, como o custo dos
bugs, algumas desculpas, desculpas teste e também
os princípios do teste de software Examinamos a definição de teste
unitário, onde
falamos sobre prós e contras e como fazer
testes unitários de forma eficaz. Também falamos sobre testes de
integração, que analisamos uma balança de
testes para
comparar o teste unitário com o teste de
integração. E então
passamos para dez testes, onde também analisamos
os prós e os contras e quando dez testes são
mais comumente usados. Por fim, analisamos uma pirâmide de
testes em que comparamos a integração
da unidade com o teste final,
e tivemos uma imagem em que
verificamos a realidade e a complexidade com base no tipo de teste Em seguida, analisamos um caso de uso. Conferimos a bolsa de estudos
Caesar. Analisamos a
análise de entrada e saída com seus requisitos
básicos. Em seguida, lançamos, certo? Fizemos um
lançamento
de produção pensando em como esse aplicativo
seria lançado. Em seguida, examinamos as
primeiras etapas do teste unitário, como testar os cálculos do
prêmio. Por fim, falamos
sobre o
teste unitário com a biblioteca X it. Discutimos por que
essa biblioteca é tão importante e por que
escolhemos usá-la. Em seguida, falamos sobre
a camada de projeto de teste no Visual Studio. Trabalhamos com o explorador
de testes, onde executamos testes unitários com base na condição
atual ou nas condições
predefinidas Em seguida, trabalhamos na formatação ou testes em que analisamos os atributos
dos fatos, os atributos da teoria,
o padrão AA e algumas convenções de
nomenclatura dos testes Em seguida, avançamos com afirmações e afirmações
fluentes, onde testamos tipos
como booleanos,
exceções, números Analisamos afirmações fluentes
para melhor legibilidade. Em seguida, examinamos a cobertura do código e suas definições básicas. Em seguida, conversamos sobre os requisitos
para testes de software. Os requisitos foram baseados na data de nascimento e no número do Seguro
Social. Criamos uma entidade de usuário, dados
de usuário, implementação de classe de
número de previdência social. Então entendemos que
precisávamos simular dados, então usamos a
biblioteca MQ para Também usamos bibliotecas como Automc para facilitar a simulação
e, em seguida, implementamos a
simulação com nosso acesso Em seguida, implementamos
os testes unitários para a idade nas classes da
Previdência Social. E, finalmente,
fizemos uma análise
da cobertura do código com
base no código que
escrevemos . Então isso foi muito. Eu gostaria de agradecer
por assistir a este curso. Espero que isso
ajude você a entender a importância dos testes
e dos aplicativos, e isso o ajude a evoluir
como engenheiro de software Lembre-se de continuar aprendendo
e evoluindo até a próxima vez.