2010-03-04 37 views
8

我希望这个问题不是'有争议的' - 我只是基本上问 - 有人在这里购买了TypeMock并且对结果感到高兴(或不高兴)?使用TypeMock的任何团队?它值得沉重的价格标签吗?

我们是一家只有12家开发商的小型开发商,其中包括2位开发经理。我们到目前为止一直在使用NMock,但有一些限制。我已经完成了研究并开始使用TypeMock,我喜欢它。它是超级干净的语法,可以让你基本模拟一切,这对于遗留代码来说非常有用。

问题是 - 我如何证明我的老板花费800-1200 $每个许可证的API有4-5个完全免费的竞争对手? 800-1200美元是Infragistrics或Telerik每个许可证花费多少 - 并且确实不是4-5个开放源代码可比较的UI框架......这就是为什么我觉得它有点过高,虽然是一个很棒的图书馆......

任何意见/经验,不胜感激。

编辑:找到最小起订量后,我以为我坠入爱河 - 直到我发现它不完全支持VB.NET,因为VB缺乏lambda子例程=(。是否有人使用MOQ for VB.NET?问题是,我们是一个混合店 - 我们使用C#我们的CRM开发和VB的一切任何指导做好大大又升值了

编辑:嗯..我找不到Isolate.WhenCalled()在Moq中有任何帮助吗?我想要在CONCRETE对象(而不是模拟对象)中存储/模拟ReadOnly属性...我可以用Isolate.WhenCalled和TM轻松做到这一点。

回答

9

我在使用TypeMock的项目已经很多个月了。我们实际上刚刚完成了完全淘汰它,赞成Moq (completely free Apache 2.0 licensed mocking framework).如果你没有看到它,你一定要检查Moq。除了具有我见过的任何模拟工具最直观的语法之外,您还可以获得编译时类型检查的好处。非常好。

与我看到的一样,TypeMock比Moq有一个显着的优点。也就是说,它可以嘲笑任何东西。这包括密封类,非虚拟方法,具体类型以及几乎所有可以抛出的东西。如果你在做ASP.Net,并且根据你的代码的结构,它实际上可以让模仿ASP.Net代码的类可能性。非常整齐。

但是 - 我们发现,如果您的代码结构良好,TypeMock的优势不会超过价格。此外,如果你不能用Moq嘲弄某些东西,那可能意味着那里有一种气味。 TypeMock让你变得懒惰,我认为代码会因此受到影响。 Moq和其他类似的嘲笑框架(RhinoMocks浮现在脑海中)确实让你在编写代码的时候考虑到了代码,特别是在可测试性方面,但我认为这是一件好事:)另外,我们的团队跑到一些令人头疼的事情是将TypeMock部署到我们的持续集成服务器上。长期以来,TypeMock是一个非常强大的工具。正如你所提到的,对于旧的遗留代码的单元测试,没有更好的产品。然而,1000块钱可以得到一个TypeMock许可证,或者几个resharper许可证,几乎10个TD.Net许可证,一个新的持续集成服务器或许多其他东西。我自己的经验表明,这不值得,但你的里程可能会有所不同!

+0

非常感谢回复 - 真棒回复。我听说莫克是一群热心人,但从未尝试过。在做出任何决定之前,我肯定会开始编写测试。我们也只是向我们的团队介绍TDD /单元测试 - 或许TypeMock可能会破坏我们太多,对于单元测试/ TDD新手的开发者,甚至可能会造成更多的损害,因为他们不会学习真正的设计正如你暗示的那样,TDD背后的校长。我也同意 - 价格对于我担心的嘲笑框架来说太过分了。就像我所说 - 为了这个价格,你可以得到像telerik这样的东西.. – dferraro 2010-03-04 03:43:33

+2

TypeMock应该真的考虑降低他们的价格点。很明显,他们是一个盈利的公司,但我只是不明白为什么你可以证明有很多免费替代方案的API有很多理由......如果它是250甚至400,那么我会说它更像是一个无脑的事情。但在800,像我们这样规模较小的公司很难证明它的价值......他们应该更多地考虑开发团队的多大/公司可能赚多少美元.. – dferraro 2010-03-04 03:45:34

+0

顺便说一句,我将给予TypeMock因为 - 是SharePoint框架。我们在这里大量使用SP,所以我可以从中看到巨大的好处......不幸的是,我们不会使用繁重的多线程应用程序,我们也不会使用Racer,因此我们将花费整整400美元来模拟SP对象... – dferraro 2010-03-04 03:46:59

2

+1 Eric的回答 - 完全同意。

它与MSTest的私人访问机制类似 - 您看到的问题很有可能是错误的。如果你最终不得不使用一些技术性的McGyvery来测试某些东西,那么有人正在做错误的事情。

当然,接下来会出现的一个对应点是有些人已经完成了某些错误(是的,我在看着你,SharePoint,WebForms和朋友),你确实需要做一些复杂的事情来处理现在的情况。

像这样的战斗往往是一个巨大的时间,回想起来很少让你感觉良好。这就好比说:“哦,我肯定需要对此进行某种形式的测试,而唯一可行的就是UI自动化,因为我们在哪里”。从这条路下来:

  • 拉能量从真正解决实际问题了 - 得到正确的测试一路的不同形式和粒度随着时间的推移和面对的事实,还有很多WROK做的和技术学习的道路上有一个系统,你可以感觉舒适的传统出发点97.92%的项目开始或倾向于在不同阶段

  • 离开你一套'编码的UI测试'你会不高兴

还有一件事 - MSR有一个最近正在推出的Moles项目,它与TM相同,即通过探查器钩子进行运行时重写。对于那些觉得自己想要/需要在自己的武器库中拥有某些东西的人来说,如果你真的在真实世界的场景中真的用尽了Moq的道路,那么你就无法重构你的出路并最终进入一个更好的地方。