一点背景：
我有一个 Web 应用程序，它从存储在 RavenDB 中的一组非规范化文档中读取。这些文档由事件处理程序创建和修改。在生产中，应用程序使用标准文档存储，该存储通过 c# API 连接到远程数据库。
当我对应用程序进行单元测试时，我将处理程序配置为使用内存中的嵌入式数据库、创建一些事件并查询预期的文档。这绝对没问题。
编写 UI 测试：
我想让我们的测试人员使用 SpecFlow 和 Selenium 编写自动化 UI 测试。在为其他应用程序（使用 SQL）实现此功能时，功能文件的执行将通过以下方式准备测试环境：
- 在本地 SQLExpress 实例中创建一个新数据库（按照惯例，每个人在他们的机器上都有相同的实例名称）
- 重新配置处理程序以使用新数据库并引发事件以创建所需状态
- 将正在测试的 Web 应用程序复制到新的临时位置并重新配置以从新数据库中读取
- 在 IIS Express 中启动 Web 应用程序（再次每个人都遵循此约定）
- 如果需要，运行功能、消隐和重建每个功能之间的状态
- 停止 IIS，删除正在测试的应用程序，并删除数据库
现在我想使用 Raven 遵循相同的方法，并且正在考虑两种方法。
首先是遵循与上述完全相同的模型。我在这里遇到的问题是如何/在哪里存储数据库，以及之后如何整理它们。服务器可执行文件可以在安装和拆卸期间以编程方式启动和停止，之后可以通过删除文件来删除数据库。我还没有尝试过，但理论上它应该可以工作。
第二种是遵循类似的方法，但用标准文档存储替换嵌入式存储（不在内存中运行）。为此，我需要修改 Web 应用程序的 IoC（如果在 xml 中使用配置，则可能）以将 IDocumentStore 解析为 EmbeddedDocumentStore。然后我像以前一样使用处理程序建立状态，然后在启动 IIS 之前处理处理程序的文档存储（似乎不可能同时运行两个使用相同嵌入式数据库的应用程序，除非我错过了某物）。
第二种方法最初似乎是更好的选择，但我遇到了一些奇怪的行为，即处理程序创建的文档与 Web 应用程序查询时返回的结果不一致。具体来说，一些子集合由处理程序填充，但在从 Web 应用程序执行的查询返回时为空。老实说，我并没有太惊讶，因为我怀疑这是打算使用嵌入式数据库的场景。此外，当我从一个应用程序跳转到另一个应用程序时，通过管理工作室查看嵌入式数据库非常困难。
所以无论如何，在冗长的描述之后，我很好奇其他人对这些方法的看法，以及是否有更好的选择我错过了。此外，我确信有许多我不知道的隐藏的 RavenDB 宝石，因此任何指向该方向的指针也会有所帮助。