Tread carefully, and make sure to experience these possibilities first. It's easiest to know what you're looking at by writing a few tests in each, and figure out what your workflow will be.
The Silverlight unit test systems out there are less mature than the officially shipped, full-fledged test frameworks for the desktop .NET environment, so your experience may vary. Understand that the Silverlight test solutions in place today (that actually run inside of a web browser) exist to specifically help folks get coverage of their code and components within the context of the Silverlight platform, and not necessarily for rapid, or easy, test-driven development and testing that you can get through the integrated Visual Studio tools.
The sandboxed security model for Silverlight makes many of the standard testing tools you may expect much more difficult.
It's also a different platform, really, so it may not make sense to perform every kind of test (example: a "load test" for a web app... you can "stress" a Silverlight app, or look into its "performance", but a "load test" is about stressing your machine that hosts the .XAP file, and is not very interesting for Silverlight apps specifically).
If you're more concerned about testing your business logic and having nice integration, strongly consider writing mockable/IoC code enough that you may be able to develop most of your app and test a version of it built as a regular desktop .NET class library ~ you could then have a subset of tests that are Silverlight in-browser only.
To your notes:
Are you actually going to be testing the web service calls with your tests? This sort of integration/client + server testing can be very, very difficult to do properly between Silverlight client code and a web service.
You won't get much integration with Visual Studio 2008's IDE for the Silverlight unit test framework. You can have a Silverlight test project / app that you can press F5 to open, and debug, in Visual Studio and run the tests. However, you won't have right-click "Run All Tests" or test case management tools working.
Automated test check-in for the Silverlight unit testing framework is something that is developing slowly, some folks have written a set of Silverlight test runners on CodePlex. You may not get this easily, and your build/test machine will need to be setup so that the build service runs instead as an actual user process, so that it can open and control web browser(s)
In the future, on the Silverlight Toolkit team, we are going to release some level of automated test support in the future, along with simple code coverage support, but these tools are not readily available as of today (Oct. '09)
我不会推荐单元测试框架，但我可以警告 MSTest 中的 Test 属性是密封的（无法在您创建的新自定义属性中继承），这与 NUnit 不同。在我看来，这一事实应该不会太重要，因为我还建议，无论您最终使用哪种测试框架，都应坚持使用其单个 Test 属性，而不是创建继承的属性。要表示特殊测试（例如您提到的 Silverlight），您应该添加一个附加属性。当您只想运行应用了自定义属性的测试（而不是所有单元测试）时，就会出现棘手的问题，并且这需要一个自定义驱动程序来进行测试。
我希望这有帮助。
I'm not going to recommend a unit testing framework, but I can warn that the Test attributes in MSTest are sealed (unable to be inherited in a new custom attribute which you create), unlike NUnit. In my mind, that fact shouldn't matter too much because I also suggest that, whichever testing framework you end up with, stick with its single Test attribute rather than creating your inherited one. To denote special tests (such as Silverlight like you mentioned) you should add an additional attribute. The tricky bit comes in when you want to only run the tests that have your custom attribute applied (as opposed to all of the unit tests), and that would require a custom driver for the tests.
发布评论
评论（2）
小心行事，并确保首先体验这些可能性。最简单的方法是在每个测试中编写一些测试来了解您正在查看的内容，并找出您的工作流程。
现有的 Silverlight 单元测试系统不如官方发布的、成熟的桌面 .NET 环境测试框架成熟，因此您的体验可能会有所不同。了解当今的 Silverlight 测试解决方案（实际上在 Web 浏览器内运行）的存在是为了专门帮助人们在 Silverlight 平台的上下文中覆盖其代码和组件，而不一定是为了您可以通过集成的 Visual Studio 工具实现快速或简单的测试驱动开发和测试。
Silverlight 的沙盒安全模型使许多您可能期望的标准测试工具变得更加困难。
实际上，它也是一个不同的平台，因此执行每种测试可能没有意义（例如：Web 应用程序的“负载测试”...您可以对 Silverlight 应用程序“施加压力”，或研究其“性能” ”，但“负载测试”是对托管 .XAP 文件的计算机施加压力，并且对于 Silverlight 应用程序来说并不是很有趣）。
如果您更关心测试业务逻辑并进行良好的集成，请强烈考虑编写足够的可模拟/IoC 代码，以便您可以开发大部分应用程序并测试作为常规桌面 .NET 类库构建的版本~ 然后您可以拥有仅在浏览器中使用 Silverlight 的测试子集。
注释：
您真的要通过测试来测试 Web 服务调用吗？在 Silverlight 客户端代码和 Web 服务之间正确执行这种集成/客户端 + 服务器测试可能非常非常困难。
您不会与 Visual Studio 2008 的 Silverlight 单元测试框架 IDE 进行太多集成。您可以拥有一个 Silverlight 测试项目/应用程序，您可以按 F5 在 Visual Studio 中打开、调试并运行测试。但是，您将无法右键单击“运行所有测试”，也无法使用测试用例管理工具。
Silverlight 单元测试框架的自动测试签入正在缓慢发展，一些人已经在 CodePlex 上编写了一组 Silverlight 测试运行程序。您可能不容易做到这一点，并且需要设置您的构建/测试机器，以便构建服务作为实际用户进程运行，以便它可以打开和控制 Web 浏览器
将来，在 Silverlight 上Toolkit 团队，我们将在未来发布一定程度的自动化测试支持，以及简单的代码覆盖率支持，但截至今天（2009 年 10 月）这些工具还不太可用
Tread carefully, and make sure to experience these possibilities first. It's easiest to know what you're looking at by writing a few tests in each, and figure out what your workflow will be.
The Silverlight unit test systems out there are less mature than the officially shipped, full-fledged test frameworks for the desktop .NET environment, so your experience may vary. Understand that the Silverlight test solutions in place today (that actually run inside of a web browser) exist to specifically help folks get coverage of their code and components within the context of the Silverlight platform, and not necessarily for rapid, or easy, test-driven development and testing that you can get through the integrated Visual Studio tools.
The sandboxed security model for Silverlight makes many of the standard testing tools you may expect much more difficult.
It's also a different platform, really, so it may not make sense to perform every kind of test (example: a "load test" for a web app... you can "stress" a Silverlight app, or look into its "performance", but a "load test" is about stressing your machine that hosts the .XAP file, and is not very interesting for Silverlight apps specifically).
If you're more concerned about testing your business logic and having nice integration, strongly consider writing mockable/IoC code enough that you may be able to develop most of your app and test a version of it built as a regular desktop .NET class library ~ you could then have a subset of tests that are Silverlight in-browser only.
To your notes:
Are you actually going to be testing the web service calls with your tests? This sort of integration/client + server testing can be very, very difficult to do properly between Silverlight client code and a web service.
You won't get much integration with Visual Studio 2008's IDE for the Silverlight unit test framework. You can have a Silverlight test project / app that you can press F5 to open, and debug, in Visual Studio and run the tests. However, you won't have right-click "Run All Tests" or test case management tools working.
Automated test check-in for the Silverlight unit testing framework is something that is developing slowly, some folks have written a set of Silverlight test runners on CodePlex. You may not get this easily, and your build/test machine will need to be setup so that the build service runs instead as an actual user process, so that it can open and control web browser(s)
In the future, on the Silverlight Toolkit team, we are going to release some level of automated test support in the future, along with simple code coverage support, but these tools are not readily available as of today (Oct. '09)
我不会推荐单元测试框架，但我可以警告 MSTest 中的 Test 属性是密封的（无法在您创建的新自定义属性中继承），这与 NUnit 不同。在我看来，这一事实应该不会太重要，因为我还建议，无论您最终使用哪种测试框架，都应坚持使用其单个 Test 属性，而不是创建继承的属性。要表示特殊测试（例如您提到的 Silverlight），您应该添加一个附加属性。当您只想运行应用了自定义属性的测试（而不是所有单元测试）时，就会出现棘手的问题，并且这需要一个自定义驱动程序来进行测试。
我希望这有帮助。
I'm not going to recommend a unit testing framework, but I can warn that the Test attributes in MSTest are sealed (unable to be inherited in a new custom attribute which you create), unlike NUnit. In my mind, that fact shouldn't matter too much because I also suggest that, whichever testing framework you end up with, stick with its single Test attribute rather than creating your inherited one. To denote special tests (such as Silverlight like you mentioned) you should add an additional attribute. The tricky bit comes in when you want to only run the tests that have your custom attribute applied (as opposed to all of the unit tests), and that would require a custom driver for the tests.
I hope this helps.