[JJaeger]

Testes unitários rodam todas as funções que vc escreve no código, por exemplo:

Vc cria uma função chamada "soma" e o teste unitário pra ela é chamar soma(1,1) e o retorno deve ser 2.
Se vc mudar o código e ele chamar soma(1,1) e der 4 o teste unitário vai falhar e vc vai ver que fez alguma cagada antes dela entrar de fato no seu projeto.

Acho que é mais ou menos isso.

nisso eu tô ligado, eu queria saber como é "no mundo real".

por exemplo: nem toda função retorna um valor comparável ou retorna qualquer valor.

---

ficar escrevendo script pra testar funções que você "sabe que vão funcionar" faz diferença no final? e, melhor, ajudam realmente na hora de refatorar? pergunta de ouro

[DK666]

Ai tem que usar algum dado mockado, tipo o teste grava uma coisa numa tabela temporaria, chama a sua função e vê ela ela alterou de certa forma, depois apaga tudo.

Mas tem coisas q são  complicadas mesmo, não é toda void q vai da pra fazer isso.

Por exemplo uma função q fiz esses dias q faz umas animações na tela e abre uma modal, o teste disso é rodar no console e ver se vai animar e mostrar a modal. Isso é bem mais difícil de aplicar principalmente em front.

[JJaeger]

Por exemplo uma função q fiz esses dias q faz umas animações na tela e abre uma modal, o teste disso é rodar no console e ver se vai animar e mostrar a modal. Isso é bem mais difícil de aplicar principalmente em front.

exatamente, tem umas coisas que são difíceis de programar e mais difíceis ainda de testar. Compensa duplicar esse trabalho escrevendo testes? Eu sei que sim, mas queria motivos sólidos e casos concretos de sucesso.

[gusyavoo]

nisso eu tô ligado, eu queria saber como é "no mundo real".

por exemplo: nem toda função retorna um valor comparável ou retorna qualquer valor.

---

ficar escrevendo script pra testar funções que você "sabe que vão funcionar" faz diferença no final? e, melhor, ajudam realmente na hora de refatorar? pergunta de ouro

No mundo real faz uma puta diferença.
Com testes bem feitos depois de um refactor vai passar muito, mas muito menos erros.
Mas assim, não pode fazer teste só pra cumprir tabela, eles tem que ser bem feito.
Na minha empresa atual nos tivemos que fazer vários refactores, e toda hora eu chorava por não ter teste, principalmente de fluxo complexo.

Vai depender muito de aplicação, mas eu gosto dos testes de aceitação, que rodam o fluxo inteiro, do endpoint até no banco.
Você não tem noção na segurança extra que isso te da na hora de um refactore de verdade, ou mesmo pra pegar bobeirinha.

[gangrena]

cara, isso é algo que eu quero aplicar mas não consigo porque não entendo. Se não for pedir muito: qual a diferença de eu programar e concertar os erros a medida que eles aparacem, infame "programação reacionária", pra eu fazer scripts de testes unitários?

---

eu genuinamente queria saber se escrever mais código pra testar código compensa

Uma das diferenças é que imagina que vc tem 10 funcionalidades que foram entregues e testadas e algum dia o cliente pede para mudar algo.

Normalmente para garantir tudo vc terá que testar todas as 10 funcionalidades manualmente e rezar para a alteração não ter quebrado nada.

Se vc tem testes unitários/instrumental, vc termina de codar dispara os testes e garante que tudo está funcionando gastando menos tempo.

Programar com testes vc gasta um pouco mais de tempo na "concepção inicial da aplicação" porém ganha muito mais tempo no decorrer do desenvolvimento e tempo de vida.

[JJaeger]

Se vc tem testes unitários/instrumental, vc termina de codar dispara os testes e garante que tudo está funcionando gastando menos tempo.

Programar com testes vc gasta um pouco mais de tempo na "concepção inicial da aplicação" porém ganha muito mais tempo no decorrer do desenvolvimento e tempo de vida.

pior que eu tô passando exatamente por isso num sistema aqui que eu codei, desenvolvimento normal, chegou na hora de concertar bug... ajeita um aqui e aparace dois ali, e eu testo tudo na mão 

sou noob pra caralho

---

No mundo real faz uma puta diferença.
Com testes bem feitos depois de um refactor vai passar muito, mas muito menos erros.
Mas assim, não pode fazer teste só pra cumprir tabela, eles tem que ser bem feito.
Na minha empresa atual nos tivemos que fazer vários refactores, e toda hora eu chorava por não ter teste, principalmente de fluxo complexo.

Vai depender muito de aplicação, mas eu gosto dos testes de aceitação, que rodam o fluxo inteiro, do endpoint até no banco.
Você não tem noção na segurança extra que isso te da na hora de um refactore de verdade, ou mesmo pra pegar bobeirinha.

eu tô apenas recentemente me deparando com refactors, antes só programava do zero, procê ver...

esses testes de aceitação precisam ser feitos tanto no front quanto no back certo? são sistemas separados, você roda uma bateria de testes no cliente e depois no servidor ou cria uma bateria única que cuida de rodar teste em ambos cliente e servidor

[gangrena]

nisso eu tô ligado, eu queria saber como é "no mundo real".

por exemplo: nem toda função retorna um valor comparável ou retorna qualquer valor.

---

ficar escrevendo script pra testar funções que você "sabe que vão funcionar" faz diferença no final? e, melhor, ajudam realmente na hora de refatorar? pergunta de ouro

Ai entra a parte de designer patterns e boas praticas de arquitetura.

Se vc tem um metodo gigante que faz tudo, é impossível ter testes decentes. 

Testes unitários não funcionam bem em aplicações cagadas, se esta tudo bem dividido por exemplo um teste pode mostrar que uma alteração de banco de dados quebrou um pedaço da aplicação.

Sobre a segunda parte, é uma ótima ajuda na refatoração, porque vc está sempre garantindo que as novas mudanças não vão estragar o que já funciona.

Testar software manualmente é um inferno de demorado.

Em iOS e Android existem teste instrumental que vc monta um teste que emula um usuário apertando botões, mudando de tela preenhecendo campos.

Isso emula muito bem o mundo real.

Um exemplo bobo de teste: um metodo calcula o saldo de uma conta e tem que dar 10.000 ao final, vc sabe que aquela conta está mockada para isso.
Então se por algum motivo e sem vc notar esse calculo falha, o teste vai te alertar sem ao menos precisar olhar para esse códgio ou "tela".

[JJaeger]

estou seriamente pensando em adotar testes unitários nos meus próximos projetos, e, se possível, ao menos em um que estou fazendo. O foda é convencer o pessoal a alocar tempo de desenvolvimento pra isso, já que não é algo que o cliente vai ver.

---

Ai entra a parte de designer patterns e boas praticas de arquitetura.

Se vc tem um metodo gigante que faz tudo, é impossível ter testes decentes. 

Testes unitários não funcionam bem em aplicações cagadas, se esta tudo bem dividido por exemplo um teste pode mostrar que uma alteração de banco de dados quebrou um pedaço da aplicação.

Sobre a segunda parte, é uma ótima ajuda na refatoração, porque vc está sempre garantindo que as novas mudanças não vão estragar o que já funciona.

Testar software manualmente é um inferno de demorado.

Em iOS e Android existem teste instrumental que vc monta um teste que emula um usuário apertando botões, mudando de tela preenhecendo campos.

Isso emula muito bem o mundo real.

Um exemplo bobo de teste: um metodo calcula o saldo de uma conta e tem que dar 10.000 ao final, vc sabe que aquela conta está mockada para isso.
Então se por algum motivo e sem vc notar esse calculo falha, o teste vai te alertar sem ao menos precisar olhar para esse códgio ou "tela".

realmente teste automático não salva código cagado  

---

acho que só o exercício de criar um teste ajude a escrever um código melhor, é muito tentador escrever funções "fazem tudo" pra resolver um problema, se você criar funções já pensando em como testa-las talvez você consiga escrever funções mais inteligíveis e modulares

---

tô com problemas chatos numa aplicação por causa dessas funções "quebra galho", vez ou outra cliente reclama que a aplicação reinicia do nada. E eu sei onde tá o problema, mas a função que resolve isso deixou de ser um quebra galho e virou uma pedra angular no componente

---

e quando essas funções quebra galho precisam confiar em outras funções quebra galho... é o feedback loop do satanás

[Amagami]

cara, isso é algo que eu quero aplicar mas não consigo porque não entendo. Se não for pedir muito: qual a diferença de eu programar e concertar os erros a medida que eles aparacem, infame "programação reacionária", pra eu fazer scripts de testes unitários?

---

eu genuinamente queria saber se escrever mais código pra testar código compensa

Nenhum código grande consegue existir (decentemente) sem cobertura de testes.

Quando você faz uma alteração em uma parte do código, como você consegue garantir que isso não quebrou alguma outra coisa? Agora pensa nisso quando você tem uma base de código de vários anos, escrita por várias pessoas diferentes.

Os testes servem pra dar essa confiança.

Um caso de sucesso são os testes que quebram quando você altera o código. Ou atualiza alguma lib.
Se não tivessem quebrado, o bug poderia ter passado para produção e causado uma catástrofe.

---

Escrever testes também te força a escrever código mais limpo, com menos responsabilidades. Como o @gangrena explicou.

[JJaeger]

Nenhum código grande consegue existir (decentemente) sem cobertura de testes.

Quando você faz uma alteração em uma parte do código, como você consegue garantir que isso não quebrou alguma outra coisa? Agora pensa nisso quando você tem uma base de código de vários anos, escrita por várias pessoas diferentes.

Os testes servem pra dar essa confiança.

Um caso de sucesso são os testes que quebram quando você altera o código. Ou atualiza alguma lib.
Se não tivessem quebrado, o bug poderia ter passado para produção e causado uma catástrofe.

sou muito garoto, nunca fiz projeto grande de verdade, só recentemente que tô pegando uns pequeno-médio porte e to passando por esses problemas... tenho medo de atualizar qualquer coisa. Ainda mais quando é código de estagiário, lol

---

Escrever testes também te força a escrever código mais limpo, com menos responsabilidades. Como o @gangrena explicou.

é exatamente o execício de pensamento que fiz no post ali. O ruim é alinhar código bem escrito com tempo de entrega...