这是一个“设计/架构”问题，因此您不需要向我提供技术细节。
我整天都可以在互联网上找到示例，展示如何运行 xunit 单元测试、记录测试结果以及如何显示它是成功还是失败，但互联网上的每个示例都是硬编码的，没有人展示如何存储的示例您的测试用例（nunit 或 junit）可以高效地构建数百或数千个测试并将其加载到您的测试引擎中。
我假设这可以使用 XML 文件或数据库表来完成。你们中的任何人都可以分享您认为存储将由测试代码加载的测试的最佳方法吗？我需要能够编写一个测试框架，最终对典型的 Web 工作流程应用程序进行数千次测试，并且我希望以正确的方式进行测试。
也许可以在“Google高级搜索”页面进行单元测试的背景下描述您的答案，该页面有很多选项和数百种变体等。
This is a "design/architecture" question and so you don't need to provide me technical details.
I can find examples on the internet all day long that show how to run a xunit unit test, log test results, and how to show if it succeeds or fails but every example on the internet is hard coded and nobody shows examples of how you store your test cases (nunit or junit) efficiently in a way that makes it possible to build hundreds or thousands of tests and load them into your test engine.
I assume this would be done using an XML file or a database table. Can any of you share what you think is the best method for storing tests that will be loaded by test code? I need to be able to write a testing framework that will ultimately have thousands of tests for a typical web workflow app, and I want to do it the right way.
Maybe describe your answer in the context of doing unit tests of the "Google Advanced Search" page, which has many options, and hundreds of variations, etc.
发布评论
评论（2）
我同意这里重要的是保持简单，并让它“自然”成长。测试与其他代码一样重要，并且应该同样积极地重构。
如果您讨论的是实际的单元测试（与测试从 UI 到数据库的整个堆栈的集成测试相反），那么在解决方案中保留运行它们所需的一切内容非常重要，以便开发人员更新源文件时将始终拥有最新的内容。此外，您应该瞄准一个简单的设置场景，其中新开发人员只需从版本控制系统获取源文件并运行测试而无需设置。
RowTest 功能非常适合简单的场景，但如果您正在处理复杂的场景，您应该查看 测试数据生成器 模式，可让您定义默认场景及其变体。
我喜欢让我的测试数据尽可能接近测试，从而使我能够真正了解测试中发生的情况。因此，我认为问题不在于您是否应该使用 XML 还是数据库，它们只是表示数据的不同格式，但您是否真的想将测试数据与测试分开？
I agree that the important thing here is to keep it simple, and let it grow 'naturally'. Tests are as important as your other code, and should be refactored just as vigorously.
If what you're talking about is actual unit tests (as opposed to integration tests where you test the whole stack from the UI through to the database) it is very important that you keep everything necessary to run them in your solution, so that developers will always have the newest stuff when updating their source files. Also, you should aim at a no-thrills setup scenario, where new developers can just get the source files from the version control system and run the tests with no setup required.
The RowTest feature is really good for simple scenarios, but if you're dealing with complex scenarios you should look into the Test Data Builder pattern that lets you define default scenarios and then variations of these.
I like to keep my test data as close to the tests as possible, thus allowing me to really see what is going on in the tests. Therefore I don't think the question is whether you should use XML or a database, they're just different formats for representing data, but whether you really want to separate your test data from your tests?
如果您正在了解“数据驱动测试”，那么您应该看看 RowTest 方法和等效方法。 NUnit 从 MBUnit 借用了这个。 xUnit 似乎有一个更可扩展的解决方案，通过 Theory 和 PropertyData，您不必在代码中指定输入；您可以从任意函数、电子表格或 SQL Server 数据库生成输入。
我从来没有需要任何超过 Rowtest 方法的东西（这也很少见）..所以不能警告你任何龙。或者，如果您无法执行上述方法，您甚至可以使用 Fit/Fitnesse 来执行此操作；尽管从技术上讲不是验收测试。
至于“测试框架”，也许YAGNI 也许你会这样做。开始吧，从小事做起，保持简单，随着时间的推移不断完善测试设计。
If you're getting at "data driven tests", then you should take a look at the RowTest approach and equivalents. NUnit borrowed this from MBUnit. xUnit seems to have a even more extensible solution to this via the Theory and PropertyData, where you don't have to specify the inputs in code ; you could generate the inputs from an arbitrary function, spreadsheet or SQL Server database.
I've never had the need for anything over the Rowtest method (which is also rare).. so can't warn you of any dragons. Alternatively you could even use Fit/Fitnesse to do this if you can't do the above approaches ; although not technically an acceptance test.
As for the 'testing framework', maybe YAGNI maybe you do. Get started, start small, keep it simple, grow the test design with time.