No .NET, o TypeMock Isolator e o Microsoft Moles permitem isolar qualquer classe, propriedade ou método - seja selado, estático, protegido ou não virtual. Então, o que era impossível zombar de Moq ou Rhino Mocks, agora não é mais o caso.

Eu sempre tive alguma aversão com a idéia de usar uma interface apenas para permitir zombarias, quando, caso contrário, apenas a classe concreta existiria. Não estou sozinho nessa visão (consulteaqui, aquieaqui) Mais tarde, está implícito que estruturas de zombaria 'modernas' não precisam mais de interfaces para teste ou injeção de dependência.

No entanto, embora não possa falar pelo Isolador TypeMock, posso dizer que o uso de Mocks no Microsoft Moles é extremamente lento. Ter código como o seguinte em testes de unidade torna a velocidade do teste muito lenta para ser usada com freqüência:

MFile.ReadAllLinesString = (s) => csvDataCorrectlyFormatted;
MDirectoryInfo.AllInstances.GetFilesString = (di,fi) => fileInfoArray;
MFileInfo.AllInstances.NameGet = (fi) => "Doesn't Matter";

Tenho certeza de que, se o método que está sendo testado fosse programado para uma interface ou classe base abstrata (para que o código do sistema de arquivos pudesse ser abstraído em um wrapper de tipos), o uso de estruturas como Moq para stubbing ou zombaria acabaria sendo mais rápido . Porém, voltamos à situação de adicionar complexidade ao código de produção, basicamente pela capacidade de testar a unidade.

Estou inclinado à opinião de que o Isolator e o Moles devem ser usados apenas quando não se pode zombar das estruturas de zombaria tradicionais. No entanto, ainda luto com a noção de ter adicionado complexidade de código de produção para fins de teste.

Estou curioso para saber o que o resto da comunidade pensa.

ATUALIZAÇÃO 10/06/10: Ao dizer que luto com a noção de ter adicionado complexidade de código de produção para fins de teste, estou me referindo à adição de uma interface (ou classe abstrata mesmo) quando, caso contrário, não for necessária, como ao criar a classe concreta métodos não selados e virtuais. O último ainda permite costuras para testes. Mesmo que mais tarde se considere necessário usar uma interface para várias implementações, eles não poderiam extraí-la da classe? Mas, a menos que surja essa necessidade, por que não seguirYAGNI.

Sou a favor dos princípios do SOLID, nos quais eles facilitam a manutenção da arquitetura de um programa. Eu não acho que esses princípios precisam ser seguidos religiosamente em todos os casos. Eu acho que o mantra, "sempre depende", entra em jogo muitas vezes. Caso contrário, resta-se a cada tipo concreto ter uma interface ou classe base abstrata, mesmo quando haverá apenas uma implementação.

Por fim, não estou dizendo isso porque, como o Isolator and Moles permite contornar as limitações de isolamento em estruturas baseadas em proxy dinâmico, não se deve ainda projetar a arquitetura para ser mantida. Em muitos casos, os princípios do SOLID são os melhores e, portanto, o Isolator ou Moles não seriam necessários. É nos casos em que a interface é usada apenas para testes que estou questionando. Estou trazendo outro ponto lateral sobre velocidade também. Se alguém optar por usar isolador e toupeiras, isso trará uma penalidade de velocidade. Portanto, certamente não acho que eles tornem obsoletas as estruturas baseadas em proxy dinâmico.