测试真实存储库
我已经设置了测试假存储库的单元测试和使用假存储库的测试。
但是测试访问数据库的真实存储库怎么样？如果将其留给集成测试，那么似乎没有直接对其进行测试，并且可能会遗漏问题。
我在这里错过了什么吗？
I've set up unit tests that test a fake repository and tests that make use of a fake repository.
But what about testing the real repository that hits the database ? If this is left to integration tests then it would be seem that it isn't tested directly and problems could be missed.
Am I missing something here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
那么，集成测试只会测试字面上的持久性或从持久层进出数据的检索。如果您的存储库正在执行与该数据相关的任何类型的逻辑（验证、如果未找到对象则抛出异常等），则可以通过伪造持久层返回的内容（是否返回查询的对象、返回代码或其他）。您的集成测试将向您保证代码可以物理地持久化/从持久化中检索数据，仅此而已。任何类型的要测试的逻辑都应该属于单元测试。
然而，有时逻辑可能存在于持久层本身中（例如存储过程）。这可能是为了提高效率，也可能只是遗留代码。这很难正确进行单元测试，因为您只能通过访问数据库来访问逻辑。在这种情况下，最好尝试尽可能地将逻辑移至代码库，以便更轻松地进行测试。可能存在针对此类场景的单元测试框架，但我不知道它们（仅仅是出于经验不足）。
Well, the integration tests would only test the literal persistence or retrieval of data to and from the layer of persistence. If your repository is doing any kind of logic concerning that data (validation, throwing exceptions if an object isn't found, etc.), that can be unit tested by faking what the persistence layer returns (whether it returns the queried object, a return code, or something else). Your integration test will assure you that the code can physically persist/retrieve data from persistence, and that's it. Any sort of logic to test ought to belong in a unit test.
Sometimes, however, logic could exist in the persistence layer itself (e.g. stored procedures). This could be for the sake of efficiency, or it could merely be legacy code. This is harder to properly unit test, as you can only access the logic by getting to the database. In this scenario, it'd probably be best to try and move the logic to your code base as much as possible, so that it can be tested more easily. There probably exist unit testing frameworks for scenarios such as these, but I'm not aware of them (merely out of inexperience).
你能建立一个真实的存储库来测试假数据库吗？
无论您做什么，这都是集成测试，而不是单元测试。
Can you set up a real repository that tests against a fake database?
Regardless of what you do, this is integration testing, not unit testing.
在合理范围内，我绝对会建议针对 DAL 进行集成测试。
我们本身不使用存储库模式（令我们懊恼的是），但我们对类似类（搜索器）的策略如下：
要点是您应该知道 O/RM 的工作原理（并且希望有测试），因此没有理由测试基本的 CRUD 行为。
您肯定需要一个“测试平台” - 内存数据库、可以签入源代码管理的本地文件支持数据库，或者（如果必须的话）共享数据库。一些测试框架提供回滚工具来恢复数据库状态；如果您在同一个测试中访问多个数据库或者（在某些情况下）您嵌入了事务，请务必小心。
编辑：请注意，这些集成测试仍将在“隔离”中测试您的存储库（保存数据库）。所有其他单元测试都将使用假存储库。
I'd definitely suggest integration tests against the DAL, within reason.
We don't use the Repository pattern per se (to our chagrin), but our policy for similar classes (Searchers) is as follows:
The gist is you should know your O/RM works (and hopefully has tests), so there's no reason to test basic CRUD behavior.
You'll definitely want a "test deck" - an in-memory database, a local file-backed database that can be checked into source control, or (if you have to) a shared database. Some testing frameworks offer rollback facilities to restore the database state; just be careful if you're hitting multiple databases in the same test or (in some cases) if you have embedded transactions.
EDIT: Note that these integration tests will still test your repository in "isolation" (save for the database). All your other unit tests will use a fake repository.
我最近讨论了一个非常类似的问题在这里。
总之：测试您的具体存储库实现是否有价值。如果您在实现中做了一些复杂的事情，那么测试它可能是个好主意。如果您使用没有自定义逻辑的 ORM，那么在该级别编写测试可能没有太大价值。
I recently covered a very similar question over here.
In summary: test your concrete Repository implementations if there's value in doing so. If you are doing something complex in your implementation, it is probably a good idea to test it. If you are using an ORM with no custom logic, there may not be much value in writing tests at that level.