tl;dr-----Desenvolva uma arquitetura onde as partes sejam pequenas, faceis de serem trocadas e tenham nomes que ajudam a entender seu comportamento.O problema----------No artigo [Seu teste unitario precisa rodar em menos de 100ms](http://aprenda-python.blogspot.com/2016/06/seu-teste-unitario-deve-rodar-em-menos-de-100ms.html) eu citei algumas dicas para testes rodarem rapido, mas e a interacao entre os componentes do seu software que vai fazer diferenca na velocidade e na simplicidade (ou complexidade) dos testes.Em outras palavras, se os testes sao lentos ou complicados, a arquitetura esta ruim. Quando isso acontece, o codigo de producao precisa ser re-estruturado (ou refatorado, como queira).Eu costumo dizer que os testes precisam fazer parte da solucao e nao do problema. A grande questao e que sempre temos prazos a cumprir e, obviamente, escolhemos ferramentas (ou formas de usa-las) que encurtam o tempo de entrega. Elas nos trazem velocidade no curto prazo (eficacia), mas nao necessariamente eficiencia a medio/longo prazo.Nesse cenario as vantagens e desvantagens da forma como desenvolvemos os testes -- e os sistemas -- precisam ser avaliadas. Se o projeto e pequeno, simples ou de curta duracao, testes um pouco lentos e uma arquitetura menos elaborada nao serao problema. Por outro lado, se o projeto e de media/longa duracao, complexo ou grande, testes lentos serao um problema serio. Outro fator que influencia na avaliacao da arquitetura e o nivel de incerteza (ou de duvidas) que existe no projeto. Vou exemplificar.Provavelmente havera poucas duvidas sobre as regras de negocio de um gerenciador de blog. Os testes podem ate ser lentos e uma arquitetura relativamente simples da conta do recado. Mas para um sistema para controle tributario, por exemplo, o cenario e outro. Havera muitas regras de negocio, varias formulas de calculo personalizaveis, legislacao que e aplicada em algumas situacoes e em outras, nao. O prazo das adequacoes normalmente e ditado por lei e o descumprimento acarreta multas altas. Enfim, o sistema e claramente maior e muito mais complexo. Voce tera muitas duvidas e muitas variacoes de regra. Por isso a arquitetura do sistema precisa ser muito mais elaborada do que no exemplo do blog. Muitos componentes precisam interagir para entregar o resultado correto. Consequentemente seus testes precisam ser mais especificos e mais rapidos. Sua rede de protecao contra acidentes precisa ser maior e mais forte. Porque se eles forem lentos e voce nao roda-los com a frequencia necessaria, estara ignorando a protecao.Algumas dicas para melhorar a arquitetura do seu sistema e acelerar seus testes-------------------------------------------------------------------------------1) Proteja suas fronteiras.Os paises defendem suas fronteiras para evitar que elementos externos e nao autorizados entrem em seu territorio e comprometam a soberania nacional. Voce deve fazer o mesmo em seus sistemas.Componentes e estruturas de dados de outros sistemas (ou bibliotecas) nao deveriam poder circular sem um controle rigido. So quem tiver "visto de entrada" pode frequentar seu sistema.Em alguns casos as fronteiras sao muito claras. Se eu preciso interagir com o Twitter, ele esta fora das fronteiras do meu sistema, certo? E se eu precisar enviar um email? Isso tambem estaria fora dos limites do meu sistema? Alguns alegam que sim, outros alegam que nao. Nesse caso eu voto pelo "sim". A nao