验收测试中的依赖性
我和一个同事正在争论。我们正在进行一个糟糕的遗留项目，并且正在慢慢添加验收测试。他认为我们应该在 gui/watin 中完成工作，然后使用低级库直接查询数据库，以获得他所说的“端到端”测试。
我们正在使用 NHibernate，我主张使用 gui/watin，然后使用那些 nhibernate 对象来进行验收测试中的断言。他不喜欢测试中 NHibernate 的依赖。我的主张是，我们已经/应该对 NHibernate 对象进行集成测试，以确保它们按照我们预期的方式与数据库一起工作，此时在验收测试中使用它们来断言正确的操作没有任何缺点。我还认为他的低级 sql 依赖将使测试变得脆弱并且在很多情况下重复业务逻辑。
我们商店中的集成测试基本上意味着它是具有依赖项的单个组件，例如 fileRepository/FileSystem Domain-NhibernateObject/Database。验收测试意味着通过 GUI 进行。单元意味着所有依赖项都已/可以被模拟/存根，并且您在内存中进行了纯测试，只有被测试的方法实际上在执行任何实际工作。让我知道我的防御是否关闭。
无论如何，任何对这个主题有意见的文章/文档/羊皮纸，你可以指出我将不胜感激。
Me and a co-worker are having a debate. We are on a craptastic legacy project and are slowly adding acceptance tests. He believes that we should be doing the work in the gui/watin then using a low level library to query the database directly for to get an 'end to end' test as he puts it.
We are using NHibernate and I advocate using gui/watin then those nhibernate objects to do the assertions in the acceptance testing. He dislikes the dependency of NHibernate in the test. My assertion was that we have/should have integration tests against the NHibernate objects to make sure they are working with DB the way we intend at which point there is no downside in using them in the acceptance test to assert proper operation. I also think his low level sql dependence will make the tests fragile and duplicate business logic in alot of cases.
Integration testing in our shop basically means its a single component with a dependency e.g. fileRepository/FileSystem Domain-NhibernateObject/Database. Acceptance testing means coming in through the GUI. Unit means all dependencies have/can be mocked/stubbed out and you've got a pure test in memory with only the method under test actually doing any real work. Let me know if my defs are off.
Anyway any articles/docs/parchment with opinions on this subject you can point me at would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
自动化测试的唯一原因是让事情更容易改变。如果您不更改它们，则可以避免手动测试。将测试与数据库联系起来将使数据库更难以更改。
恐怕将它们与 NHibernate 对象绑定也没有多大帮助！
您系统的用户不会使用数据库或 NHibernate。他们如何获得利益（或为其他利益相关者提供利益）？他们如何才能知道它运行良好？如果您可以在验收测试中捕获这一点，您将能够更改底层代码和数据，同时仍然保持应用程序的价值。如果有人根据数据生成报告，为什么不生成相同的报告并检查其内容是否符合您的预期？如果数据被另一个系统读取，您能否获取该系统的副本并查看它向其用户输出的内容？
无论如何，这是我的观点 - 使验收测试尽可能接近业务价值 - 并且 这是我写的一篇博客文章，可能会有所帮助。您还可以尝试 Yahoo 上的行为驱动开发小组，他们有相当多的他们之间的经历。
哦，进行集成测试来检查您的 (N)Hibernate 绑定是否良好是一个好主意。为我们节省了几个项目。
The only reason you'd ever automate tests is to make things easier to change. If you weren't changing them, you could get away with manual testing. Tying the tests to the database will make the database much harder to change.
Tying them to the NHibernate objects won't help very much either, I'm afraid!
The users of your system won't be using the database or NHibernate. How do they get the benefit (or provide the benefit to other stakeholders)? How will they be able to tell that it's working well? If you can capture that in the Acceptance Tests, you'll be able to change the underlying code and data while still maintaining the value of your application. If someone generates reports from the data, why not generate the same reports and check that their contents are what you expect? If the data is read by another system, can you get a copy of that system and see what it outputs to its users?
Anyway, that's my opinion - keep acceptance tests as close to the business value as possible - and here's a blog post I wrote which might help. You could also try the Behavior Driven Development group on Yahoo, who have a fair bit of experience amongst them.
Oh, and doing integration tests to check that your (N)Hibernate bindings are good is an excellent idea. Saved us on a couple of projects.