Quanto a Testes:
A ideia de contexto pode ser relativa: Contextos podem ter subcontextos. Sempre foco meus primeiros testes no requisito, e somente depois este requisito é quebrado em varias funcionalidades que vão gritando por novos testes até chegar à indivisibilidade mencionada. Ao final do produto os testes que foram quebrados garantem o funcionamento da unidade e os primeiros testes escritos servem para garantir que a engrenagem do processo funciona. Quando alguma funcionalidade falha eu tenho pelo menos dois testes falhando: O da unidade e o da ‘engrenagem’ (que ainda sim não deixa de ser uma unidade).
Quanto a Interfaces:
Gosto de fazer só o básico para o atendimento do requisito e é seguindo esta linha que acredito que a criação de interfaces deveria acontecer principalmente nos contextos em que a utilização de IoC se faz necessária, ou seja, quando você chega na fronteira tecnologia x negócio.
O que tenho percebido nos projetos que acompanho é que desenvolvedores tendem a fazer uma força enorme para reaproveitar coisas, mesmo que este reaproveitamento seja só o nome do método e nada diz para sua implementação ou nada fala para seu design. Assinar uma classe com um contrato de interface precisa ter um motivo, precisa de um grito: “Eu sou serializavel! Eu sei persistir!”. E este grito normalmente tem haver com a tecnologia imposta. Já vi coisas abomináveis como interfaces IContaContabil para assinar ContaDebito e ContaCredito, mesmo que as posteriores herdem de uma “ContaContabil” em comum. Sempre cabe um depende em nossa área mas o que tenho visto é que o depende esta virando regra…
↧
Por: marcusalexandresilva
↧