Muito relevante. Por exemplo, recentemente eu corrigi um bug que ficava enviando requisições de renovação de token bro back. Mas eu causei outro bug, que omitia os erros retornados no back. Um colega foi lá e corrigiu o erro. Adivinha o que aconteceu? Kkkk

Se o projeto precisa sair logo do papel, não é relevante, vaj testando na hora e na mão mesmo, se não, ele é 100% relevante e importante para que o proneto não tenha falhas (ainda que possa ir mesmo com testes) para produção. Vamos lembrar que testes é um sistema também, então o sistema de teste pode ter erro o que vai causar erro no sistema principal.

Eu já tenho uma dúvida importante sobre apps que utilizam a localização do dispositivo. Eles devem ser testados somente em movimento ou o movimento também pode ser simulado no PC?

Depende do prazo estabelecido

Bom, eu estou criando meus apps no modo solo e passando tanto pelo over business (pmi, pmcamvas, bacanas, lean startup, agile/scrum, etc) quanto pelo over arquitecture (patterns, testes, escalabilidade, etc). Então, o que decidir fazer essa semana? Estou idealizando o negócio primeiro, focando em prototipagem de telas já no APP para ser testavel (já pensando em uiux). Segundo passo, desenvolver o básico com TDD e BDD. Por básico entenda o mínimo para funcionar e ser de fácil manutenção. +

Aprendi com um produto que estou desenvolvendo que é uma boa prática manter uma quantidade específica de teste unitário pra pelo menos as funções mais primordiais do sistema. Sem isso, você não garante assertividade

Essencial

Teste unitário já me salvou de mandar bug pra produção, troquei 1 linha e quebrei dezenas de testes do sistema hahahhahahahha e era uma linha inofensiva pensando no caminho feliz da funcionalidade

Testes não é perca de tempo, e nao atrasa entrega de feature, dito isso quem não cria é por opção mesmo lkkkk

Eu fiz um post sobre isso no linkedin. Nos contras eu coloquei que é um código que testa código, quem garante que o teste tá certo?