fala Dev beleza seja bem-vindo à segunda aula da jornada desenvolver testes eu sou André casque e nesse evento você tá aprendendo o caminho que qualquer deve pode seguir para subir de nível na carreira entregando código de qualidade e o código de qualidade é aquele que tem três características fundamentais ele resolve os problemas do usuário é fácil de manter e não tem bugs nessa segunda aula da jornada eu vou te mostrar Quatro Coisas que Todo deve precisa saber para entregar código de qualidade Olha como esse conhecimento aí fez diferença no jeito que o Wellington trabalha Cara
isso para mim virou um mantra tipo assim quando a pessoa tá falando as coisas eu eu falo tá mas pera aí eu interrompo porque as pessoas elas vão logo pro como né não faz isso você faz aquilo principalmente aquelas que pensam que entende de programação aí eu falo tá para aí para pera Mas o que você quer com isso fala qual é o objetivo do negócio assim o que que o negócio espera é economizar dinheiro é tempo Ah é ter uma informação mais apurada você viu como a visão dele mudou do como fazer para por
fazer depois que você entender como esse conteúdo influencia no desenvolvimento do software eu tenho certeza que a sua visão também vai mudar porque depois de ver não dá mais para desver e no final dessa aula eu vou te dar uma informação que é muito importante e que eu tenho certeza que vai te ajudar muito nessa jornada aí para melhorar a qualidade do seu código e subir de nível na carreira mas antes de começar vamos dar aquela revisada no que você aprendeu lá na primeira aula eu gosto de fazer isso porque além de relembrar os pontos
principais também vai ficar mais fácil para você conectar com o conteúdo da aula de hoje então Ó lá na primeira aula Você viu que todo deve aprende a programar de um jeito errado Ou pelo menos de um jeito que não favorece a qualidade do código não que isso te impeça de trabalhar você até consegue entregar suas atividades manter seu emprego de repente até conquistar algumas coisas aí na sua carreira só que às vezes o código não sai como você gostaria ele vai com bug paraa produção usuário reclama gera estresse gera retrabalho ou às vezes você
fica estagnado fica estagnada aí na sua carreira você trabalha trabalha trabalha e o seu salário não muda a situação na sua empresa não muda nada tudo isso acontece porque lá no começo da sua carreira te ensinaram algumas coisas do jeito errado e essas coisas que você aprendeu errado ou que você não aprendeu fazem você cometer três grandes erros que acabam com a qualidade do software Primeiro Erro fazer tudo que seu usuário Por mais que você ache que o usuário conhece muito bem o software e que ele sabe o que precisa ser feito na maioria das
vezes ele não sabe o segundo erro focar demais Em lógica e em Recursos da linguagem não adianta fazer o software mais moderno do mundo com as coisas mais legais da tecnologia se ele não resolve os problemas do seu usuário e o terceiro erro escrever código linguição você entrega código ruim Difícil de Entender Difícil de alterar e nunca melhora E aí você entra num Loop Infinito porque falta tempo para fazer um código melhor aí falta conhecimento entrega de qualquer jeito gera bug em produção que é urgente E aí falta tempo de novo e eu gosto de
trazer esses erros à tona que é para você criar consciência para saber que eles existem Como que você vai melhorar alguma coisa no seu trabalho se você nem percebe que tá errando que você tá indo por um caminho onde é muito mais difícil entregar com qualidade mas agora que você já sabe eu tenho certeza que isso aí vai ficar martelando na sua cabeça toda vez que acontecer então já dá pra gente ir pro próximo passo da jornada agora se você veio direto para essa aula eu recomendo fortemente que você volte um passo e assista a
primeira aula antes porque eu fiz um resumo bem rápido aqui sobre os três erros mas lá na primeira aula tem muito mais informação de contexto principalmente para você entender como eu descobri esses erros né E por que eles te atrapalham tanto na hora de entregar código de qualidade então ó se você não viu essa primeira aula volta lá e assiste beleza Bom a essa altura da jornada você já deve estar aí pensando a parada toda é sobre fazer teste unitário não é isso Então mostra logo esse código de uma vez eu quero ver logo como
é que faz esse negócio só que não é bem assim que funciona lembra lá do segundo erro que você foca muito em como fazer as coisas e que para nós programadores esse como se traduz em código pensar que escrever código de teste unitário vai resolver todos os seus problemas de qualidade também entra na conta desse erro é claro que se você quer entregar código de qualidade o teste unitário é uma parte fundamental da coisa só que é exatamente isso ele é uma parte ele é só um pedaço do processo e ele ainda fica lá no
final do processo ou seja tem outras coisas que você precisa aprender antes porque quando você tá estudando sobre teste unitário todos os exemplos que você vê eles são super fáceis de testar todo código lá é bem feitinho é organizado mas quando você chega no trabalho a realidade infelizmente é muito diferente você vai mexer no método e ele tem lá mil linhas é um código linguição aí bate um desespero porque você não tem a menor ideia de como testar um trombo desse ou então você vai criar um monte de teste que só dá trabalho para escrever
e para manter e que no final não testa Nada de útil E como que eu sei que isso acontece com você porque aconteceu comigo também eu contei isso lá na primeira aula Aliás não só comigo acontece com todo mundo Deixa eu te mostrar um exemplo bem simples só para você entender que o teste unitário sozinho muitas vezes ele não é suficiente Olha só imagina que o usuário precisa de um programa que calcula o valor parcelado de um pedido aí você cria esse código aí ó em csharp programa pede pro usuário informar o valor total e
a quantidade de parcelas aí tem essa classe pedido que tem um campo valor total e tem um método chamado calcular valor parcelado que pega o valor total e divide pela quantidade de parcelas e ainda tem uma regrinha aqui ó não pode parcelar em mais de 12 vezes e nesse caso aí o programa não calcula e já devolve direto o valor à vista agora vamos ver os testes desse método calcular valor parcelado são três testes o primeiro testa um parcelamento em duas vezes segundo testa em 12 vezes e aí o terceiro testa a regra do limite
máximo de parcelas passando 13 vezes vamos rodar os testes aqui para ver se tá tudo ok rodou ó olha aí tudo verdinho é porque todos os testes passaram então em teoria tá tudo certo não é isso vamos executar o programa para ver se eu informar R 100 parcelado em duas vezes dá 50 beleza se eu informar r$ 100 e parcelar em 12 vezes Beleza vai dar 100 se eu informar 1300 e parcelar em 13 vezes aí não é para dar 100 tem que dar 1300 por causa lá da regra do limite beleza funcionou agora e
se eu informar R 100 e zero parcelas será que vai funcionar olha aí ó deu oito e assim não sou um G da matemática mas eu acho que essa conta aí não deve tá certa né E só para você não se assustar achar que o você Chapa é uma porcaria e fez tudo errado na verdade esse cálculo lí ele retornou infinito é que na hora de gerar os caracteres aqui foi a linha de comando que mostrou como oito Beleza você viu os testes unitários Você viu o que o código fazia não parecia que tava tudo
certo que o código Era bom que o teste era bom só que tem bug E é isso que a a maioria dos deves faz é desse jeito que a galera Trabalha com testes e talvez você também esteja trabalhando desse jeito você olha pro código e tenta testar tudo que você consegue cobrir todas as situações ali para não deixar nenhuma brecha nenhuma parte do código sem teste Aí você entrega acha que vai ter qualidade mas no final entrega com bug não adianta focar só no código da aplicação e nem só no código de teste é que
nem plantar uma flor não adianta jogar semente na Terra ou enfiar uma muda em qualquer vazinho a minha esposa adora flores e eu posso te afirmar que desse jeito não funciona você precisa cuidar da terra precisa preparar o vaso precisa saber quais são as características da flor se ela é grande se ela é pequena se a raiz ocupa muito espaço e de repente precisa de um vaso maior tem que entender como ela se desenvolve também se precisa de sol se precisa de sombra se gosta de vento se demora para crescer se pode regar todo dia
não é só semente terra e eu tô reforando bastante esse ponto porque se você não entender isso de verdade tem uma grande chance de você também ficar 13 anos tomando pancada tentando fazer teste unitário de um jeito aleatório na esperança de entregar as coisas com qualidade assim como eu fiquei lembra que eu contei isso lá na primeira aula é por isso que nessa segunda aula eu quero te mostrar aquilo que me faltava quando eu comecei E que provavelmente ainda falta para você e falta também pra maioria dos devs porque ninguém ensina todo mundo só fala
para você fazer teste unitário Ah faz um teste aí que vai dar bom e às vezes dá bom só que na maioria das vezes infelizmente não vai dar então ó vamos lá qual que é o conhecimento que tava faltando quando eu comecei são os quatro pilares do software de qualidade e agora é importante deixar uma coisa bem clara aqui ó por que que eu chamo essa parada de quatro pilares Pensa numa casa ou num prédio os pilares são aquelas partes da estrutura que sustentam todo o peso da construção ou seja eles são a base da
coisa e Tem três coisas muito importantes para você entender sobre isso a primeira delas sem os pilares não tem como levantar construção Se todas as paredes o teto tudo vai se apoiar nos pilares você não consegue começar a construir se não tivesse esses quatro pilares primeiro por isso que eu chamo esses quatro conhecimentos de Pilares porque são eles que vão dar essa sustentação eles que vão dar o suporte para você entregar código de qualidade a segunda coisa cada Pilar precisa ser forte porque se é para sustentar a construção toda ele não pode ser construído com
palitos de sorvete então não adianta você só saber que esses quatro conhecimentos existem você precisa masterizar cada um deles é claro que Para começar você não precisa ser um expert em todos eles senão você vai ficar parado ou parada aí e não vai sair do lugar o objetivo aqui da jornada é colocar você no caminho é fazer você andar então você pode ir evoluindo aos poucos ao longo da carreira e aí quanto mais você dominar cada um desses Pilares mais carga você vai conseguir aguentar você vai conseguir projetos maiores códigos mais complexos e situações mais
difíceis e a terceira e última coisa os quatro pilares são necessários você pode começar uma construção só com dois pilares é claro que pode mas a medida que a construção avança Você vai precisar dos outros Pilares porque senão a obra vai ficar incompleta Ou de repente as paredes começam a ficar meio torta ali ou se você tenta subir mais um andar sua casa vai cair aí então se você quer entregar um código com qualidade de verdade você vai precisar desses quatro conhecimentos Em algum momento que é para ter uma base sólida Para ter segurança para
ter uma estrutura que suporta aí o seu crescimento no futuro se você deixar um deles de lado vai chegar uma hora em que vai ser difícil continuar vai por mim E aí nessa hora você trava você desanima Larga a mão e aí volta a fazer as coisas de qualquer jeito como era antes Beleza então ó agora que você já entendeu as premissas Vamos ver aí quais são os quatro pilares do software de qualidade o primeiro Pilar base teórica sobre testes mas André não sou tester eu não sou que eu sou Dev Por que eu tenho
que ficar aprendendo teoria de teste se o meu trabalho entregar código Olha só se você ainda pensa que o seu trabalho é só entregar código volta lá na aula um da jornada e assiste de novo a parte onde eu conto como que eu estourei a conta bancária de um monte de clientes porque eu não sabia testar software direito todo deve precisa aprender a testar e como qualquer outra coisa na sua carreira o começo do aprendizado é a base teórica Eu já falei isso lá na primeira aula a gente valoriza demais o código O como fazer
as coisas e dá Pouca importância pro teste em si a gente acha que o teste é só um detalhezinho que dá para resolver rapidão ali lá no final da sua entrega a gente acha que é uma parada super simples que dá para resolver intuitivamente que você não precisa ficar estudando teste como você estuda programação que não tem necessidade é só ir fazendo que aí uma hora você aprende e assim mesmo mesmo que você se ache diferente porque você sempre tenta pensar na qualidade gosta de testar o máximo possível fala a verdade você já parou para
estudar alguma coisa sobre a base teórica dos Testes Se for para chutar eu arriscaria que não o máximo que você faz é estudar sobre o teste unitário e olha lá ainda porque muito deve não faz nem isso e a culpa disso de novo não é só sua é que ninguém se preocupa em ensinar esse tipo de coisa pros deves a gente vê muito desse conhecimento em cursos e palestras de q e é por isso que eu sempre digo que a gente tem muito a aprender com eles por exemplo Será que você sabe quais são os
tipos de teste de software e para que que cada tipo serve eu escuto muitas muitas perguntas sobre isso que que é um teste unitário eh como que funciona o teste de integração Qual que é a diferença entre teste de integração e o teste funcional via Mex aparece um Dev por aqui que quer tirar dúvida sobre teste unitário mas aí na verdade quando me mostra o código ele tá fazendo outros tipos de teste e ele nem sabe que aquilo não é teste unitário outra coisa muito comum são os devos que nem sabem direito o que que
é um bug e eu sei que parece que é uma coisa de que você vê bug todo dia você sabe exatamente o que que é só que a grande maioria dos devs acha que o bug é só um erro técnico é só uma Exception um Object reference not set que estour ali no meio da execução do seu programa e cara tem várias coisas que acontecem durante a utilização do software que podem se encaixar na definição de bug entender isso pode te ajudar por exemplo a negociar seu os prazos com o usuário para consegir criar código
com qualidade sem ficar atrasando as entregas Geralmente os devs também não se preocupam com o processo em si para entend como fazer testes consistentes que validam de verdade que precisa e TZ esse seja o seu caso se você testa só o que d na telha ou se você testa no improviso mesmo ali vai lembrando das alterações e o que que precisa testar ali tudo na hora que você apertou o debug Aliás a própria definição de teste ela já não é uma parada muito unânime entre os deves se você perguntar eles vão dizer ué testar é
só ver se código Tá certo não é isso que é uma definição muito aberta e que dá margem para várias interpretações como você viu lá na primeira aula é esse pensamento aí que gera cultura de bang bang onde você aponta o dedo pro usuário dizendo que ele não sabe o que ele quer E aí o usuário te aponta o dedo de volta dizendo que você entendeu de tudo errado que você não perguntou nada e se você ficou curioso ou curiosa aí sobre essa definição Segura as pontas aí que daqui a pouco a gente vai falar
mais sobre isso e o segundo Pilar análise de requisitos Esse aí é um tema bem controverso hoje em dia né antigamente quando eu comecei a programar análise de requisitos era uma parada muito mais forte né tanto que quando eu comecei eu era analista programador e tinha muitas empresas que tinha cargo só para análise mesmo um analista que fazia só os levantamentos e entregava uma documentação super mastigada que o Dev Só precisava escrever o código Até hoje ainda tem empresas que seguem nesse modelo Aí talvez não seja muito muito comum mas ainda tem a ideia em
si ela não é tão ruim só que na maioria das vezes isso não funcionava porque era só mais uma pessoa no meio da cadeia do software para dar Pitaco e que ficava discutindo o que que é bug o que que tava fora do escopo do projeto e tudo era muito mais burocrático também né a gente usava vários diagramas diferentes para ilustrar o que precisava ser feito o Dev ali tinha que saber coisas como rup como uml E aí muitas vezes esses diagramas eles não ajudavam tanto assim né no papel e tudo parecia que era sempre
muito bonito mas quando você ia pra prática na hora de escrever o código mesmo às vezes as coisas não encaixavam e aí claro que os dbos fazzi o que dava para fazer ou seja eram mais coisas para estudar mais documento para usuário aprovar mais tempo indo pro ralo com coisa que não era tão útil por causa disso O AJ ou a agilidade né ganhou muita força aí nos últimos anos lin scrum kamban Extreme programming que são formas diferentes de trabalhar mas que tem um lema em comum que é priorizar o software funcionando ao invés de
ter uma documentação abrangente e eu particularmente eu gosto bante desse pensamento ágil só que teve uma galera que comeou a levar isso muito ao pé na letra e aí os devis criaram meio que uma aversão à document vees D até coir né quando vocêa no assunto mas assim eu não aqui para dizer qual dos dois lados é melhor até porque o melor mesm é aquilo que funcion você funcion seu time e que funciona sua empresa eu só quero te mostrar uma outra perspectiva sobre esse assunto análise de requisitos não é sobre documentações ou sobre ter
processos mais ágeis até tem uma certa relação com isso aí mas não é esse o objetivo o objetivo da análise de requisitos é entender o que o seu usuário precisa e quando eu falo entender é entender de verdade não é só para ficar ouvindo o seu usuário falar ali dizer que entendeu para ir embora da reunião logo é sobre você fazer as perguntas certas com direcionamento certo para fazer com que o seu usuário Fale qual é o problema que você precisa resolver para ele porque muitas vezes ele não te fala qual é o problema ele
só quer te falar a solução e às vezes até uma solução técnica teve uma vez que uma galera do meu time eles queriam me mostrar uma alteração ali que eles estavam fazendo E aí Surgiu uma dúvida eles queriam me opinião aí eles começaram a me contar o que era funcionalidade que eles criaram uma tabela que já tinha uma ideia do que que ia mexer no código ali só que essa funcionalidade ela era muito parecida com uma que já existe no sistema uma que já tem um desenho estabelecido já tem um processo pronto então eu questionei
se não dava para usar essa mesma estrutura que já existia E aí a gente direcionava a solução para um caminho muito mais simples é claro que o time não gostou muito né porque o trabalho já tava em andamento Eles já estavam fazendo algumas coisas e aí eles só queriam naquele momento né só queriam tirar uma dúvida mais técnica ali comigo mas quando a gente sentou todo mundo junto ali para avaliar o problema entender o propósito da alteração ficou muito claro que não precisava criar um monte de coisa nova E aí no final eu descobri que
quem pediu para criar uma tabela nova ali no sistema foi o usuário porque ele achou que o melhor jeito de resolver o problema era criando uma tabela mesmo sem ter a menor ideia do impacto ou do trabalho que isso pode gerar no nosso dia a dia lembra que você viu lá na primeira aula que fazer tudo que o usuário pede é um erro Esse aí é um exemplo da vida real aconteceu comigo veio direto do campo de batalha e eu tenho certeza que você já passou por situações muito parecidas ou talvez até passa até hoje
entendeu que seus clo precisa entender qual problema ele quer que você resolva isso que é analisar requisitos e tem mais hein ó encarar as coisas desse jeito aí também vai tirar a sua atenção do como do código ali das tecnicalidade ou seja fazer uma boa análise de requisitos também Evita o erro número dois que você viu lá na primeira aula que é só focar em código você vai começar a pensar mais em resultado esperado que é um conceito que é fundamental para entregar código de qualidade e que tem tudo a ver com a definição do
teste se você analisar a estrutura de um teste você vai ver que dá para dividir ele em três partes diferentes a primeira parte é o resultado esperado o que que deve acontecer quando eu rodar esse teste a segunda parte é a ação aquilo que vai ser executado para gerar um resultado o que que você vai fazer e a ter Tera é a comparação a gente vai verificar se o resultado da ação bate com resultado esperado se bater o teste passou se não bater o teste falhou logo a parte mais importante do teste é você descobrir
qual é o resultado esperado o melhor exemplo para para ilustrar isso daí é o teste de gravidez a ação nesse caso aí é o menos importante de tudo você pode comprar um teste de farmácia por exemplo e fazer xixi num potinho ou você pode ir até um laboratório e fazer um exame de sangue no fim das contas dá meio que na mesma porque o que importa mesmo de verdade é saber se a mulher tá grávida ou não e outra ninguém vai atrás de fazer um teste desses daí se não tiver interesse de saber o resultado
pode ser uma coisa que você deseja ou talvez uma coisa que você não deseja mas a sua atenção ela tá focada no resultado porque para você é isso que importa ou seja Sem resultado esperado não tem teste e quando a gente aprende a programar ninguém ensina a pensar no resultado esperado todo mundo ensina a executar ação que é o como a gente aprende que resultado esperado ele é só uma consequência do código é um um resultado que o seu código vai cuspir que é só você pensar na lógica nos com E aí você dá um
return no final lá e tá tudo beleza é por isso que você não sabe por onde começar seu teste unitário porque você não aprendeu a pensar em resultado esperado antes de sair digitando código e é por isso que é tão importante você aprender a analisar requisitos porque é ele que vai te ajudar a entender o problema vai alinhar a expectativa de entrega com usuário e de quebra ainda vai evitar que você faça tudo que ele pede sem você pensar direito no que precisa fazer desde que você faça análise do jeito certo também né claro até
porque e falando assim parece que você vai precisar aí de 300 reuniões um monte de documento para formalizar tudo aí com o usuário e que obviamente não vai dar tempo de fazer isso aí no seu trabalho mas calma porque na aula três eu vou te mostrar que você só precisa de um documento e esse único documento ele serve para entender o que o usuário precisa para combinar com ele o que vai ser feito e para definir o que você vai alterar no código e o terceiro Pilar a arquitetura de software sempre que você escuta a
palavra arquitetura eu tenho certeza que surge um monte de outras palavras na sua cabeça difícil complexo avançado Sênior experiência conhecimento técnico e na cabeça dos devs o arquiteto de software ele é tipo uma evol do programador né E talvez até seja mesmo porque tem muitas empresas que criam esse caminho na hierarquia dos cargos e depende também da sua visão de carreira né se essa é a sua opinião tá tudo bem o problema é que isso te leva concluir que a arquitetura é um negócio avançado é uma parada que não é para iniciantes e que você
não precisa aprender no início da sua carreira e não é nada disso não tem nada a ver você pode sim aprender os conceitos da arquitetura de software aliás Pode não Você deve aprender a menos que você não queira melhorar a qualidade do seu código é claro que arquitetura ela tem lá as suas complexidades Assim como qualquer outra coisa na área de programação e a arquitetura em especial ela tem um mar de conhecimentos diferentes cara um monte de coisa que você pode abordar com profundidades diferentes também Mas relaxa aí porque assim eh você não precisa ficar
entrando nessa paranoia a coisa mais importante que você precisa entender para melhorar a qualidade do seu código e que pode ser aplicado também em qualquer momento da sua carreira de Dev é que a arquitetura é um jogo de limites e responsabilidades lembra o que eu falei lá sobre o terceiro erro na aula anterior que o problema é que você faz um código linguição mas você deixa de fazer alguma coisa com ele depois o que você deixa de fazer é definir esses limites e responsabilidades e olhando pro código o que que seria definir limites né É
você pensar em como separar o seu código em partes menores pensa no software que você mexe hoje aí por mais velho e mal feito que ele seja provavelmente ele não tem só um arquivo com uma função que começa lá na linha um e vai até a linha 50.000 não é assim ele normalmente tem vários arquivos tem várias classes vários métodos e o mais engraçado é que quando você aprende orientação objetos primeira coisa que te ensinam é a orientação objetos é uma forma de modelar o mundo real dentro do software e beleza faz todo sentido isso
mas então por que que a gente vê por aí métodos com o nome de calcular imposto devido que calcula ula o valor do Imposto atualiza o valor no banco notifica sistema de estoque manda e-mail para cliente faz até um cafezinho Quantas vezes você já não mexeu em um código desses ou melhor quantas vezes você já não fez um código desses definir limites é a arte de separar o seu código linguição em partes menores em métodos ou funções menores porque métodos menores são mais fáceis de entender e código mais fácil de entender é mais fácil de
testar E se o código é mais fácil de entender e é mais fácil de testar qual você acha que a probabilidade de um código desse debugs você tá vendo como não precisa de mágica você não precisa de inteligência artificial para integrar código de qualidade é só você aprender as coisas certas e aprender a aplicar essas coisas na sequência certa e falando em sequência e não adianta só separar o seu código também em partes menores porque talvez você esteja aí pensando tá se é só separar beleza um Ctrl C cont contrl V resolve tudo ou um
cont CRL x né Às vezes você nem precisa também de CRL ctrl v Ctrl x contrl v qualquer ideia decente que você usa hoje em dia ela já tem recursos de refon que você só seleciona ali um bloco de código clica na opção extrair para novo método e pronto já tá lá código separado bonitão do jeito que o japonês lá falou que é para fazer só que isso aí não funciona não adianta você picotar seus métodos gigantes em métodos pequenos as partes que você separa elas precisam fazer sentido e o que dá sentido pros seus
métodos é entender a responsabilidade de cada um deles ou seja o que que esse método deve fazer por que ele existe lá no meu código imagina um apartamento pronto para morar com móveis com eletrodoméstico tudo decorado ali ele vai ter paredes certo e aí as paredes elas servem para dividir os ambientes para dividir os cômodos e não são divisões totalmente aleatórias Provavelmente o banheiro não fica do lado da cozinha e a varanda ela tamb não fica do lado de dentro né perto da porta de entrada porque Cara isso não faz o menor sentido Agora imagina
esse mesmo apartamento com as mesmas paredes só que vazio Sem móveis sem eletrodoméstico sem decoração sem nada dentro tá tudo muito bem dividido pelas paredes mas não dá para saber direito Qual que é a função de cada cômodo você pode montar um closet no quarto você pode usar suí como sala você pode também montar uma cozinha gigante se você quiser ou seja você só vai ter essa noção do que faz o que não faz sentido quando você entende Qual que é a responsabilidade de cada espaço desse móvel É por isso que você precisa entender a
responsabilidade de cada parte do seu método gigante antes de sair picotando n em um método menor que é para evitar que o seu código fique confuso porque se você não entende o que que o código faz você vai alterar ele de qualquer jeito sem saber nem se tá certo ou se tá errado e aí a tendência de gerar bugs vai aumentar você tá vendo como as coisas elas vão se conectando tudo que você aprende sobre a arquitetura de software tem a ver com limites e responsabilidades design patterns Solid padrões arquiteturais como arquitetura limpa ou arquitetura
hexagonal baixo acoplamento alta ão especialização mas assim ó como eu já disse relaxa aí não precisa correr não precisa sair estudando tudo que existe de mais novo e mais moderno sobre arquitetura na aula três eu vou te mostrar Quais são os principais assuntos que você precisa focar para entregar código de qualidade então ó não perde essa aula porque vai fazer bastante diferença no seu código e o Quarto e último Pilar o teste unitário ou também cham chamada aí de teste de unidade Talvez uma nomenclatura até melhor provavelmente é um dos motivos de você tá aqui
na jornada desenvolver testes que é para aprender alguma coisa sobre teste unitário e é claro que ele precisa est nessa lista porque ele é a melhor ferramenta que um Dev pode usar para entregar um código de qualidade e essa é a parte importante para destacar aqui o teste unitário é uma ferramenta ele faz parte do como e eu sei que lá na aula um eu falei que é um erro focar demais no como né no no código ali mas uma hora ele precisa aparecer aqui nessa lista certo lembra lá do exemplo da flor não adianta
dubar Terra preparar o vaso se você não planta semente no final tudo faz parte do processo como que eu faço para saber se o meu código resolve problema do usuário depois que você entendeu o problema você faz teste unitário Ah mas como que eu sei se o meu código faz sentido se ele tá fácil de dar manutenção você faz teste unitário Se você não conseguir Provavelmente o código tá difícil de alterar é por isso que na minha opinião ele é a melhor ferramenta do Dev para entregar código de qualidade primeiro porque ele testa código diretamente
ali é um programa que testa outro programa E aí por ter essa característica de ser um programa você pode alterar usando visual Studio você pode versionar seu código usando o Git você pode complementar seus testes com extensões com componentes externos como qualquer outro código que você mexe no seu trabalho e ele também ajuda a saber quando você terminou uma alteração quando você terminou uma correção ou uma nova funcionalidade ali no sistema você já deve ter passado por isso algumas vezes você cria uma lista de tudo que você precisa fazer aí você vai lá altera o
código testa ali manualmente né com Studio usando debug dá um check na sua lista inteirinha todas as atividades Aí você fica olhando pra tela fica pensando eu acho que acabou né Será que tá faltando alguma coisa cara fala a verdade não bate uma insegurança quando você termin as coisas parece que você terminou mas você não sabe direito se terminou fazendo o teste unitário do jeito certo com método certo não tem essa terminou de codar terminou de programar ali rodou todos os testes todos os testes passaram já era cara finaliz atividade finalizada não tem mais o
que fazer esse sentimento de você saber que terminou e que você fez tudo que precisa ser feito não tem preço e o teste unitário ainda tem o benefício de ser um teste automatizado por natureza se você mexe 300 vezes no código para fazer uma alteração o certo é fazer o mesmo teste manual 300 vezes e é óbvio que você não vai fazer isso eu no seu lugar também não faria porque é chato porque cansa 300 vezes tá maluco é por isso que os deves não testam direito porque fazer teste manual cansa ninguém quer ficar fazendo
a mesma coisa 300 vezes no dia é chato enche o saco o teste unitário resolve esse problema você vai ter que investir um tempo ali para fazer uns testes Mas uma vez que eles estão prontos é só você apertar um botão e Executar tudo claro que eventualmente você vai ter que dar manutenção no código dos Testes também né que Afinal sempre que o código mudar o teste unitário vai quebrar junto para te avisar que o resultado mudou aí você pode verificar se a sua alteração tá certa ou se você fez alguma bobagem e o código
não devia ter quebrado isso claro se você fizer bons testes se você aprender a fazer teste unitário do jeito certo porque quem não sabe fazer quem não tem um método quem não tem uma técnica para fazer teste quem só acha que fazer teste unitário é pegar o código colar no chat GPT e pedir para ele gerar teste unitário pode ter muita dor de cabeça e literalmente mesmo quando você fica horas ali tentando testar um código sem nem saber por onde começar ou quando você faz um monte de teste inútil que não testa nada e só
gera mais trabalho na hora de dar manutenção no código ou quando você manda sua alteração pra produção e fica lá rezando para não dar problema que é a famosa programação entada Esperança você altera o código publica em produção e Reza para tudo dar certo agora se você não é muito fã da programação orientada a esperança se você entender os pilares do código de qualidade mas ainda não sabe direito como fazer essas coisas do jeito certo aí eu tenho uma informação muito importante para te dar lembra que eu falei dela lá no começo da aula eu
recebo várias mensagens no meu canal do YouTube no meu perfil do Instagram perguntando se eu posso ajudar a analisar um código se eu posso ajudar com um problema se eu tenho um curso onde eu ensino tudo isso e é por isso que eu decidi abrir mais uma turma do desenvolver testes o curso online onde eu ajudo devs a subir de nível na carreira entregando código de qualidade se você quer realmente abandonar a programação orientada a esperança Essa é a sua chance de aprender o meu método aprender as minhas técnicas e ter o meu acompanhamento pessoal
na sua jornada no final da próxima aula aula 3 lá eu vou te explicar tudo direitinho lá vai ter como funciona quando começa a turma o que que tá incluso Como que você faz para entrar Quais são as formas de pagamento tudo bem detalhado ali lá no final da aula 3 você vai saber tudo isso daí então se você se interessou anota aí na sua agenda e não perde a terceira aula que vai ser lá na sexta-feira para fechar essa aula e ajudar a fixar o conteúdo vamos revisar tudo que você aprendeu hoje você viu
que um código de qualidade ele é sustentado por quatro pilares primeiro Pilar é base teórica sobre testes não adianta atrás de acert se você nem sabe direito o que que é um bug saber pelo menos o básico da teoria vai te ajudar a entender muita cois durante o desenvolvimento segundo Pilar é análise de requisitos não é para entupir o seu projeto de documentação é para entender os problemas do usuário e te ajudar a pensar menos no Como programar focar em resolver problemas terceiro Pilar é a arquitetura de software o melhor remédio paraar de escrever código
linguição é aprender a definir limites e responsabilidades dentro do seu código ou seja identificar onde começa uma coisa e termina outra para quebrar o seu método de mil linhas ali em partes menores que fazem sentido e o quarto Pilar é o teste unitário que é a melhor ferramenta dos 10 para entregar código de qualidade desde que você aprenda a fazer esses testes do jeito certo Claro e aí ó na próxima aula eu vou mostrar um exemplo prático para você entender como que esses conceitos da jornada fazem diferença na qualidade da sua entrega São coisas que
dá para você aplicar no código que você mexe todo dia mesmo que ele não seja muito fácil de mexer eu tenho certeza que essa aula a aula 3 vai virar bastante Chaves aí na sua cabeça vai mudar muita coisa aí na forma como você programa e como prometido lá no final da aula 3 eu vou contar todos os detalhes para você aproveitar essa oportunidade e entrar pra próxima turma do desenvolver test se você quiser me ajuda na sua jornada profissional claro então ó Fica de olho no seu e-mail Fica de olho lá no grupo do
WhatsApp que eu vou te avisar assim que a aula 3 estiver no ar beleza um grande abraço e até a próxima aula
