任何优秀的软件架构师都会同意，当有人从头开始构建新项目时，他不能在开始时进行边界（数据库，GUI，外部服务等......） 实际上，他应该独立于任何后端构建他的软件的核心，并将它们视为应用程序的一种“插件”。
TDD和验收测试为每个新功能提供了促进：
然而，很多文章都解释说，验收测试是一个非常真实的端到端测试，涉及GUI（浏览器（例如使用Selenium）或其他界面）。
接受测试是否应基于应用程序的HEART并且不受任何边界限制？它会迫使我考虑GUI例如...：s
什么是好习惯？为每个功能写两种验收测试？：一种用于业务逻辑，另一种用于确保GUI良好运行？
答案 0 :(得分：3)
首先让我建议阅读Steve Freeman和Nat Pryce的Growing Object-Oriented Software, Guided by Tests。到目前为止，它是迄今为止我读过的最好的软件测试书。它的优点在于作者不关注像Calculator类这样的虚拟用例，而是使用TDD来测试add(int, int)方法。这太傻了。相反，他们使用Swing接口构建功能完备的应用程序，通过XMPP构建网络连接以及相当多的业务逻辑。这让我们回到你的问题。
上述书籍的作者使用各种技术和工具，但他们始终保持TDD实践。对于单元测试，他们选择mockito但是对于接受和集成测试，他们实际上自动启动应用程序（GUI）和XMPP测试服务器。
他们设法通过在测试和GUI之间实现高度分离来测试GUI测试。您应该在名为驱动程序的抽象背后隐藏您的用户界面（Web，桌面，SOAP Web服务等）。您的测试仅使用placeOrder("Foo")等高级方法与驱动程序进行交互。每个驱动程序（BrowserDriver，SwingDriver）都明白这意味着什么，并浏览您的网页或点击胖GUI上的按钮。
如果您可以在不更改测试的情况下更改GUI，但只需更改基础驱动程序 - 您就做对了。