Teste de software eficaz com . NET e XUnit | Caio Sousa | Skillshare
Pesquisar

Velocidade de reprodução


1.0x


  • 0.5x
  • 0.75x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 1.75x
  • 2x

Teste de software eficaz com . NET e XUnit

teacher avatar Caio Sousa, Software Engineer

Assista a este curso e milhares de outros

Tenha acesso ilimitado a todos os cursos
Oferecidos por líderes do setor e profissionais do mercado
Os temas incluem ilustração, design, fotografia e muito mais

Assista a este curso e milhares de outros

Tenha acesso ilimitado a todos os cursos
Oferecidos por líderes do setor e profissionais do mercado
Os temas incluem ilustração, design, fotografia e muito mais

Aulas neste curso

    • 1.

      Apresentação

      3:22

    • 2.

      Fundamentos do teste de software

      5:51

    • 3.

      Teste de unidade

      3:55

    • 4.

      Teste de integração

      3:33

    • 5.

      Testes de ponta a ponta

      4:30

    • 6.

      A pirâmide de testes

      3:18

    • 7.

      Apresentação de estudo de caso

      2:23

    • 8.

      Aplicando testes de unidade

      4:27

    • 9.

      Começando com Xunit

      8:09

    • 10.

      Trabalhando com o Test Explorer

      5:38

    • 11.

      Melhorando a redabilidade de seus testes

      9:04

    • 12.

      Mais sobre afirmações

      9:00

    • 13.

      Afirmações fluentes

      9:19

    • 14.

      Cobertura de código e dicas

      5:40

    • 15.

      Teste de unidade com xUnit Review

      1:50

    • 16.

      Requisitos de números de segurança social

      9:09

    • 17.

      Acesso de dados simulados com MOQ

      9:09

    • 18.

      Testando os requisitos por unidade parte 1

      5:47

    • 19.

      Testando os requisitos por unidade parte 2

      8:40

    • 20.

      Testando os requisitos por unidade parte 3

      4:05

    • 21.

      Cobertura de código

      4:28

    • 22.

      Conclusão do curso

      4:10

  • --
  • Nível iniciante
  • Nível intermediário
  • Nível avançado
  • Todos os níveis

Gerado pela comunidade

O nível é determinado pela opinião da maioria dos estudantes que avaliaram este curso. Mostramos a recomendação do professor até que sejam coletadas as respostas de pelo menos 5 estudantes.

1

Estudante

--

Projeto

Sobre este curso

Aprenda como criar testes unitários em aplicativos C#. Explore os diferentes tipos de testes, como testes de integração e testes de ponta a ponta. Entenda por que o teste é importante e que tipo de teste escolher com base no cenário em que você está. Neste curso, você vai criar testes com a biblioteca xUnit e entender o valor real na entrega de software quando a qualidade é considerada.

Vamos analisar casos de uso, analisar as entradas e saídas de um determinado caso de uso, descobrir como os testes de unidade podem preparar você para fazer as perguntas certas e fornecer valor a uma equipe de desenvolvimento de software por meio de uma proposta de validação de caso de uso por meio de testes unitários eficazes.

Este curso abrange, mas não está limitado à configuração do xUnit no . NET em uma camada de projeto de teste. A criação e o gerenciamento de roupas de teste usando um explorador de teste. A escrita de aulas de teste e métodos de teste. Validação de resultados de testes por meio de afirmações, simulação de dependências para serviços externos e muito mais. Após este curso, você vai entender como criar um conjunto robusto de testes que ajudam a garantir a qualidade e a correção do seu . Código NET.

Convido você a se juntar a mim nesta oportunidade emocionante para aumentar suas habilidades com testes de software em . NET.

Conheça seu professor

Teacher Profile Image

Caio Sousa

Software Engineer

Professor

Hello, I'm Caio.

Visualizar o perfil completo

Level: Intermediate

Nota do curso

As expectativas foram atingidas?
    Superou!
  • 0%
  • Sim
  • 0%
  • Um pouco
  • 0%
  • Não
  • 0%

Por que fazer parte da Skillshare?

Faça cursos premiados Skillshare Original

Cada curso possui aulas curtas e projetos práticos

Sua assinatura apoia os professores da Skillshare

Aprenda em qualquer lugar

Faça cursos em qualquer lugar com o aplicativo da Skillshare. Assista no avião, no metrô ou em qualquer lugar que funcione melhor para você, por streaming ou download.

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.