Abra um arquivo que não existe em Python e open() lança um FileNotFoundError que sobe para fora da sua função. Faça o mesmo em Go e os.ReadFile devolve um valor error ao lado de um slice de bytes nil. Mesma falha, duas formas de código completamente diferentes em volta dela. A diferença não é cosmética. Ela decide se quem chama pode ignorar a falha por acidente, e se o compilador percebe quando isso acontece. ...
Uma classe que salva um usuário no banco de dados, manda um e-mail de boas-vindas e formata um recibo precisa de uma única mudança para quebrar duas funcionalidades com as quais não tem nada a ver. Você toca no template do e-mail e arrisca a escrita no banco. Você toca no layout do recibo e arrisca o e-mail. SOLID são cinco regras que atacam esse tipo de emaranhado a partir de ângulos diferentes, e compartilham uma ideia: uma classe deve mudar por um único motivo, e o resto do código deve depender do que algo promete fazer, não de como faz isso. ...
Aqui está uma classe que você não consegue testar com um teste unitário sem um banco de dados ativo e um servidor SMTP funcionando: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService cria o próprio SqlOrderRepository e SmtpEmailSender com new, connection string e tudo mais. Todo teste que toca PlaceOrder precisa de um banco de dados Orders real e um servidor de e-mail real, ou falha antes mesmo da sua assertion rodar. A lógica que você quer testar tem duas linhas: salvar o pedido, enviar a confirmação. Ela está soldada a duas classes concretas que você não consegue trocar. ...
Você abre uma função para corrigir um bug de uma linha e quarenta minutos depois ainda está rastreando qual ramo define qual variável. Três tarefas sem relação entre si estão soldadas em um único bloco, e nenhuma delas tem nome. Você puxa um fio e não consegue saber quais outros se movem. Isso é spaghetti code, e o nome não tem nada a ver com indentação ou estilo de nomenclatura. Ele descreve o fluxo de controle: a execução pula entre condições da mesma forma que um fio de macarrão cruza todos os outros na tigela, e seguir um único caminho até o fim significa manter quatro níveis de if na cabeça ao mesmo tempo. ...