Nhibernate 验收测试中的依赖关系

我和一个同事正在辩论。我们正在进行一个craptastic遗留项目，并正在慢慢添加验收测试。他认为，我们应该在gui/watin中完成这项工作，然后使用低级库直接查询数据库，以获得他所说的“端到端”测试

我们使用的是NHibernate，我主张使用gui/watin，然后使用这些NHibernate对象在验收测试中进行断言。他不喜欢在考试中依赖NHibernate。我的主张是，我们已经/应该对NHibernate对象进行集成测试，以确保它们以我们所希望的方式与DB一起工作，在验收测试中使用它们来断言正确的操作不会有任何负面影响。我还认为，他对sql的低水平依赖将使测试变得脆弱，并在许多情况下复制业务逻辑

我们车间的集成测试基本上意味着它是一个具有依赖关系的单个组件，例如fileRepository/文件系统域NhibernateObject/数据库。验收测试意味着通过GUI进入。单元意味着所有依赖项都已经/可以被模拟/剔除，并且您在内存中得到了一个纯粹的测试，只有被测试的方法实际执行任何实际工作。如果我的DEF关闭，请告诉我

---

无论如何，如果你能给我提供任何关于这个问题的文章/文件/羊皮纸，我将不胜感激

自动化测试的唯一原因是使事情更容易更改。如果你不改变它们，你可以不用手动测试。将测试绑定到数据库将使数据库更难更改

把它们绑在NHibernate对象上恐怕也帮不了什么忙

您系统的用户不会使用数据库或NHibernate。他们如何获得利益（或向其他利益相关者提供利益）？他们将如何判断它是否运行良好？如果您可以在验收测试中捕捉到这一点，那么您将能够在保持应用程序价值的同时更改底层代码和数据。如果有人根据数据生成报告，为什么不生成相同的报告并检查其内容是否符合您的预期？如果数据由另一个系统读取，您能否获得该系统的副本并查看它向用户输出的内容

无论如何，这是我的观点——让验收测试尽可能接近业务价值——这可能会有所帮助。你也可以在雅虎上试试，雅虎在这方面有相当多的经验

---

哦，做集成测试来检查您的（N）Hibernate绑定是否良好是一个很好的主意。为我们节省了几个项目。

那么你是说验收测试应该只知道公共界面（UI或web服务）？例如，添加发票。验收测试将在一页中添加发票，然后查看另一页的发票列表，并确保其显示正确的信息？我想我收集的是验收测试将模拟最终用户的交互。这就是想法，是的。例如，与其检查某个特定菜单是否显示在菜单栏中，为什么不实际使用该菜单？用户不在乎菜单是否在那里，他们是否不能使用它。这也有助于鼓励开发人员开发垂直切片的端到端功能，让利益相关者参与进来并获得反馈，而不是横向分割，花几个月的时间来制作任何东西。我必须在仔细考虑后说，我同意Lunivore。我和Mike O'Brien的真正问题是我们跨越了一些测试类型的界限，所以我们的行话都搞乱了。