有团队使用 TypeMock 吗？是否值得高昂的价格标签？
我希望这个问题不是“有争议的” - 我只是基本上问 - 这里有人购买了 TypeMock 并对结果感到满意（或不满意）吗？
我们是一家小型开发商店，只有 12 名开发人员，其中包括 2 名开发经理。到目前为止我们一直在使用 NMock，但也有局限性。我已经做了研究并开始使用 TypeMock，我喜欢它。它是超级干净的语法，基本上可以让你模拟一切，这对于遗留代码来说非常有用。
问题是 - 我如何向我的老板证明每个许可证花费 800-1200 美元购买一个有 4-5 个完全免费的竞争对手的 API 是合理的？ Infragistrics 或 Telerik 每个许可证的成本是 800-1200 美元 - 而且肯定没有 4-5 个开源可比的 UI 框架...这就是为什么我觉得它有点定价过高，尽管它是一个很棒的库...
非常感谢任何意见/经验。
编辑：找到 MOQ 后，我以为我坠入爱河 - 直到我发现 VB.NET 不完全支持它，因为 VB 缺少 lambda 子例程 =(。有人在 VB.NET 使用 MOQ 吗？问题是我们是一家混合型商店 - 我们使用 C# 进行 CRM 开发，使用 VB 进行其他所有工作，非常感谢任何指导
编辑：嗯.. 我不能。在 Moq 中找到 Isolate.WhenCalled() 等效项...这里有什么帮助吗？我想存根/模拟 CONCRETE 对象（不是模拟对象）的 ReadOnly 属性...我可以使用 Isolate.WhenCalled 轻松做到这一点TM。起订量怎么样？？？
I hope this question is not 'controversial' - I'm just basically asking - has anyone here purchased TypeMock and been happy (or unhappy) with the results?
We are a small dev shop of only 12 developers including the 2 dev managers. We've been using NMock so far but there are limitations. I have done research and started playing with TypeMock and I love it. It's super clean syntax and lets you basically mock everything, which is great for legacy code.
The problem is - how do I justify to my boss spending 800-1200$ per license for an API which has 4-5 competitors that are completly free? 800-1200$ is how much Infragistrics or Telerik cost per license - and there sure as hell isn't 4-5 open source comparable UI frameworks... Which is why I find it a bit overpriced, albeit an awesome library...
Any opinions / experiences are greatly appreciated.
EDIT: after finding MOQ I thought I fell in love - until I found out that it's not fully supported in VB.NET because VB lacks lambda sub routines =(. Is anyone using MOQ for VB.NET? The problem is we are a mixed shop - we use C# for our CRM development and VB for everything else. Any guidence is greatly appreciated again
Edit: hmm.. I can't find Isolate.WhenCalled() equivalen in Moq... Any help here? I want to stub/mock out a ReadOnly property of a CONCRETE object (not of a mocked object)... I could easily do this with Isolate.WhenCalled with TM. How with Moq???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我参与的项目使用 TypeMock 已有好几个月了。实际上，我们刚刚完全淘汰它，转而使用 Moq（完全免费的 Apache 2.0 许可的模拟框架） . 如果您还没有看过 Moq，那么您绝对应该查看一下。除了拥有我见过的任何模拟工具中最直观的语法之外，您还可以获得编译时类型检查的好处。很不错。
在我看来，TypeMock 比 Moq 有一个显着的优势。也就是说，它可以嘲笑任何东西。这包括密封类、非虚拟方法、具体类型以及您可以添加的几乎所有其他内容。如果您正在使用 ASP.Net，并且根据代码的结构方式，它实际上可以使在类后面模拟 ASP.Net 代码成为可能。相当整洁。
然而 - 我们发现，如果您很好地构建代码，TypeMock 的好处不会超过价格。此外，如果您无法使用 Moq 来嘲笑某物，则可能意味着那里有气味。 TypeMock 让你变得懒惰，我认为代码可能会因此受到影响。 Moq 和其他类似的模拟框架（我想到了 RhinoMocks）确实让您在编写代码时思考代码，特别是在可测试性方面，但我认为这是一件好事:) 此外，我们的团队遇到了尝试将 TypeMock 部署到我们的持续集成服务器时遇到了一些令人头疼的问题。
长话短说，TypeMock 是一个非常强大的工具。正如您提到的，对于旧的遗留代码的单元测试，没有很多更好的产品。然而，1000 美元可以让你获得一个 TypeMock 许可证，或者几个 resharper 许可证，近十个 TD.Net 许可证，一个新的持续集成服务器或许多其他东西。我自己的经验表明这不值得，但您的里程可能会有所不同！
The project I'm on used TypeMock for many months. We actually just finished completely phasing it out in favor of Moq (completely free Apache 2.0 licensed mocking framework). You should definitely check out Moq if you haven't seen it. In addition to having the most intuitive syntax of any mocking tool I've seen, you get the benefits of compile time type checking. Very nice.
TypeMock has one significant benefit over Moq as I see it. Namely, it can mock anything. This includes sealed classes, non virtual methods, concrete types and pretty much anything else you can throw at it. If you're doing ASP.Net, and depending on how your code is structured, it can actually make mocking ASP.Net code behind classes a possibility. Quite neat.
However - We found that if you structure your code well, the benefits of TypeMock do not outweigh the price. Further, if you can't mock something with Moq, it probably means there's a smell there. TypeMock lets you be lazy, and I think that the code can suffer as a consequence. Moq and other mocking frameworks like it (RhinoMocks comes to mind) do make you think about your code as you're writing it, especially in terms of testability, but I would argue that's a good thing :) Further, our team ran in to several headaches trying to deploy TypeMock to our continuous integration server.
Long story short, TypeMock is a very powerful tool. As you mention, for unit testing old legacy code there aren't many better products. However, 1000 bucks gets you one TypeMock license, OR, a couple of resharper licenses, almost ten TD.Net licenses, a new continuous integration server or many other things. My own experience suggests that it's not worth it, but your mileage may vary!
+1埃里克的回答 - 完全同意。
它类似于 MSTest 的私有访问器机制 - 您很有可能错误地看待问题。如果你最终不得不使用一些技术性的 McGyvery 来测试某些东西，那么有人就做错了。
当然，接下来作为对立面出现的事情是，在某些情况下，有人已经做了错误的事情（是的，我正在看着你，SharePoint、WebForms 和朋友），而你确实需要做一些复杂的事情为了应对现在的情况。
像这样的战斗通常会耗费大量的时间，回想起来很少会让你感觉良好。这类似于说“哦，我确实需要对此进行某种形式的测试，而唯一可行的是 UI 自动化，因为我们所处的位置”。沿着这条路走下去：
将精力从真正问题的真正解决方案上抽离——随着时间的推移，对不同形式和粒度进行适当的测试，并面对有大量工作要做和需要学习技术的事实考虑到 97.92% 的项目从不同阶段开始或趋向于不同阶段的遗留起点，在拥有一个您可以放心的系统的道路上，
给你留下一组你不会满意的“编码的 UI 测试”
一件事 - MSR 有一个 Moles 项目，他们最近一直在拉皮条，它做与 TM 相同的事情，即通过分析器钩子进行运行时重写。对于那些觉得自己想要/需要在自己的武器库中拥有一些东西作为备份的人来说，如果您在现实世界的场景中确实用起订量来摆脱困境，而您无法重构自己的出路并最终到达一个更好的地方，那么这可能会很有用。
+1 Eric's answer - completely agree.
It's similar to MSTest's private accessors mechanism - there's a very strong chance you're looking at the problem wrong. If you end up having to use some technical McGyvery to test something, somebody is Doing Something Wrong.
Of course, the next thing that gets trotted out as a counterpoint is that there are cases where someone has already Done Something Wrong (Yes, I'm looking at you, SharePoint, WebForms and friends) and you really do need to do some complex in order to deal with the situation as it is right now.
Fighting battles like this can often be a huge timesink which in retrospect rarely makes you feel good. It's similar to saying "Oooh, I definitely need to get some form of testing on this, and the only thing that's going to work is UI automation because of where we are". Going down that road:
pulls energy away from a the real solution to the real problem - getting proper testing all the way down of different forms and granularity over time and facing the fact that there's lots of wrok to do and techniques to learn on the road to having a system you can feel comfortable about given the Legacy starting point that 97.92% of projects start from or tend towards at various stages
leaves you with a set of 'Coded UI tests' that you won't be happy with
One more thing - MSR has a Moles project they've been pimping lately which does the same sort of thing as TM, i.e., runtime rewriting via profiler hooks. Might be useful to people that feel they want/need to have something in their arsenal as backup if you ever do really run out of road with Moq in a real world scenario that you cant refactor your way out of and end up in a better place.