Só uma complementação para as pessoas q não sabem mto sobre testes não confundirem, TDD não é sinônimo de testes de unidade e sim uma forma de programar baseado em testes, onde os testes são criados primeiros e depois vem o código de produção.

Eu por exemplo, já trabalhei no estilo TDD puro (na época eu era fullstack), mas para quem é mais baseado em telas (front e mobile, por exemplo), TDD é massante demais, pois nosso foco principal é tela e tela se inicia pelo design. Por isso sempre faço primeiro os códigos, depois os testes, pois pelo menos pra mim isso é o q funciona.

Mas não significa q não use TDD. Eu uso normalmente em pequenos códigos e especializados voltados pra regra de negócio dentro do mobile, pois nesses códigos são simples usar TDD. Primeiro vc define as entradas e os resultados (ou seja, cria o teste) de um tal método, depois vc cria o código com base nesses testes, ou seja, TDD. Claro q resumi bem aqui, assim como o felprangel, recomendo leia sobre TDD q compensa bte ver como funciona essa forma de programar.
Eu aprendi sobre essas diferenças depois de ler Test-Driven Development do Mauricio Aniche, mas imagino q qqr livro possa ensinar isso. O legal q nesse livro mostrou coisas mais complexas como qndo expandir o código em novas classes e tals, mas nunca consegui chegar nesse nível via TDD, prefiro do modo tradicional, codificar primeiro e depois aplicar testes neles.

Só mais uma coisa para qm está iniciando nisso, uma coisa q acredito é q não existe o certo e o errado de como fazer os testes, o q existe é, se vc não fizer testes hj, vc pode pagar o preço no futuro.