Pergunta

Espero que essa pergunta não seja 'controversa' - estou basicamente perguntando - alguém aqui comprou o TypeMock e ficou feliz (ou infeliz) com os resultados?

Somos uma pequena loja de desenvolvedores de apenas 12 desenvolvedores, incluindo os 2 gerentes de desenvolvimento. Estamos usando o NMOCK até agora, mas existem limitações. Eu fiz pesquisas e comecei a brincar com o TypeMock e adoro isso. É uma sintaxe super limpa e permite que você basicamente zombe de tudo, o que é ótimo para o código legado.

O problema é: como justificado para o meu chefe gastando 800-1200 $ por licença para uma API que possui 4-5 concorrentes que são completamente gratuitos? 800-1200 $ é quanto custo infragistrics ou telerik custa por licença-e com certeza não é 4-5 de código aberto comparável a estruturas de interface do usuário ... e é por isso que acho um pouco caro, embora uma biblioteca incrível ...

Quaisquer opiniões / experiências são muito apreciadas.

EDIT: Depois de encontrar o MOQ, pensei em me apaixonar - até descobrir que ele não é totalmente suportado no VB.net porque o VB não possui sub -rotinas lambda = (. Alguém está usando o MOQ para vb.net? O problema é que somos um misto Loja - Usamos C# para o nosso desenvolvimento de CRM e VB para todo o resto. Qualquer guia é muito apreciada novamente

EDIT: Hmm .. Não consigo encontrar isolado. Quero arrancar/zombar de uma propriedade reado de um objeto concreto (não de um objeto zombado) ... eu poderia facilmente fazer isso com isolado. Como com MOQ ???

Foi útil?

Solução

O projeto em que estou no tipo de tipo usado por muitos meses. Na verdade, acabamos de terminar completamente de eliminá -lo em favor de MOQ (estrutura de zombaria licenciada Apache 2.0 completamente gratuita). Você definitivamente deve conferir o MOQ se não o viu. Além de ter a sintaxe mais intuitiva de qualquer ferramenta de zombaria que eu já vi, você obtém os benefícios da verificação do tipo de tempo de compilação. Muito agradável.

O TypeMock tem um benefício significativo sobre o MOQ como eu o vejo. Ou seja, pode zombar de qualquer coisa. Isso inclui classes seladas, métodos não virtuais, tipos de concreto e praticamente qualquer outra coisa que você possa jogar nele. Se você estiver fazendo asp.net e, dependendo de como seu código está estruturado, ele pode realmente tornar o código ASP.NET de zombaria por trás das classes uma possibilidade. Muito legal.

No entanto - descobrimos que, se você estruturar bem seu código, os benefícios do TypeMock não superam o preço. Além disso, se você não pode zombar de algo com MOQ, provavelmente significa que há um cheiro lá. O TypeMock permite que você seja preguiçoso, e acho que o código pode sofrer como conseqüência. MOQ e outras estruturas zombeteiras como essa (Rhinomocks vem à mente) fazem você pensar no seu código enquanto está escrevendo, especialmente em termos de testabilidade, mas eu diria que isso é uma coisa boa :) Além disso, nossa equipe correu para Várias dores de cabeça tentando implantar o TypeMock em nosso servidor de integração contínua.

Para encurtar a história, o TypeMock é uma ferramenta muito poderosa. Como você mencionou, para testar o código legado antigo, não há muitos produtos melhores. No entanto, 1000 Bucks recebe uma licença de tipo de tipo de tipo ou algumas licenças de resharper, quase dez licenças de TD.NET, um novo servidor de integração contínua ou muitas outras coisas. Minha própria experiência sugere que não vale a pena, mas sua milhagem pode variar!

Outras dicas

+1 Resposta de Eric - Concordo completamente.

É semelhante ao mecanismo de acessores privados da Mstest - há uma chance muito forte de que você está olhando para o problema errado. Se você acabar tendo que usar algum McGyvery técnico para testar algo, alguém está fazendo algo errado.

Obviamente, a próxima coisa que é trotada como contraponto é que há casos em que alguém já fez algo errado (sim, estou olhando para você, SharePoint, Webforms e amigos) e você realmente precisa fazer algum complexo Para lidar com a situação como é agora.

Lutar batalhas como essa pode ser um grande tempo de times, que em retrospecto raramente faz você se sentir bem. É semelhante a dizer "Oooh, eu definitivamente preciso obter alguma forma de teste nisso, e a única coisa que vai funcionar é a automação da interface do usuário por causa de onde estamos". Indo pelaquela estrada:

  • Afasta a energia de uma solução real para o problema real - obtendo testes adequados até diferentes formas e granularidade ao longo do tempo e enfrentando o fato de que há muitos wrok para fazer e técnicas para aprender no caminho para ter um sistema que você Pode se sentir confortável com o ponto de partida do legado de que 97,92% dos projetos começam ou tendem a em vários estágios

  • deixa você com um conjunto de 'testes de interface do usuário codificados' com os quais você não ficará feliz

Mais uma coisa - a MSR tem um projeto de toupeiras que eles têm sido destacados ultimamente, o que faz o mesmo tipo de coisa que a TM, ou seja, reescrita em tempo de execução por meio de ganchos de perfil. Pode ser útil para as pessoas que sentem que querem/precisam ter algo em seu arsenal como backup, se você realmente ficar sem estrada com MOQ em um cenário do mundo real que você não pode refatorar e acabar em um lugar melhor .

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top