对于测试驱动的 SharePoint 开发有哪些好书和在线资源？
我正在寻找文章、教程、示例、链接、视频、书籍或任何可以帮助我开始测试驱动 SharePoint 开发的内容。
我也有兴趣了解这种做法的优缺点以及需要注意的事项。
I am seeking articles, tutorials, examples, links, videos, books, or anything to get me started with the Test Driven SharePoint Development.
I am also interested to find out pros and cons of this practice and things to look for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您不需要专门了解 Sharepoint。测试驱动开发的概念足够通用，适用于任何编程语言或框架。
wiki 可以帮助您入门，谷歌中有很多链接可以从那里开始。
但是，如果您确实想要一些 Sharepoint 特定文章，可以阅读 The Sharepoint Cowboy 的 文章 和一篇关于 21 个应用程序。
I don't think you need to understand it specific to Sharepoint. The concept of test-driven development is general enough to be applicable to any programming language or framework.
The wiki can get you started, and there are plenty of links in google to go from there.
But, if you really want some Sharepoint specific articles, there is The Sharepoint Cowboy's article and an article on 21 apps.
我同意 Larry 的观点，“正常”测试驱动适用于 SharePoint 就很好。
您应该查看 TypeMock 进行单元/集成测试。它是一个单元测试/伪造框架，允许您伪造 SharePoint 对象。不确定它是否仍然是唯一这样做的，但它肯定是一个好产品。
我发现在 SharePoint 中进行测试驱动开发比常规 .NET TDD 更耗时，主要是因为 SharePoint 对象更复杂且更难以隔离。例如，SharePoint 列表通常取决于内容类型，而内容类型又取决于网站栏等。这意味着您必须付出更多的努力才能使其正常工作。
一个很大的优点（无论如何在我看来）是一旦你的设置完成，你就可以快速工作。设置测试环境（如果您通过 UI 进行）是一件很痛苦的事情。这需要很长时间。例如，如果您需要创建列，那么每次更改使用它的代码时都会通过 UI 进行内容类型，您将损失大量时间。更重要的是，如果您的测试失败并且您需要删除内容类型，因为您破坏了某些内容。通过单元测试/伪造的 SharePoint 对象，您很快就能做到这一点，而且您将很快更好地了解 SharePoint 对象的工作原理。
I agree with Larry, "normal" test-driven applies to SharePoint just fine.
You should look at TypeMock for your unit / integration tests. It's a unit-test / faking framework that allows you to fake SharePoint objects. Not sure if it's still the only one that does it, but it certainly is a good product.
I find that doing test-driven development in SharePoint is a bit more time-consuming than regular .NET TDD, mostly because SharePoint objects are more complex and harder to isolate. For example, a SharePoint list often depends on a content type, which depends on site columns, etc. It means that you have to put it a bit more work to get something working.
A big pro (in my eyes anyway) is that once your setup is done, you can work fast. Setting up your environment for a test (if you're doing it through the UI) is a pain. It takes a long time. For example, if you need to create your columns, then your content type though the UI every time you make a change to code that uses it, you'll lose a lot of time. Even more so if your test fails and you need to delete your content type because you broke something. Going with unit tests / fake SharePoint objects, you'll be able to do that in no time, plus you'll quickly get a better understanding of how the SharePoint objects work.