该应用程序公开Web UI（HTML资源），该Web UI调用安全的REST API（具有JSON序列化），然后将其委派给核心域模型（事务性应用程序服务和业务实体） ）独立于任何投放机制。 REST API最终将公开。使用关系数据库和ORM可以实现持久性。使用标准的Java / Spring / Hibernate技术堆栈。
如果要进行纯TDD，我们将编写以下测试：
Selenium / Web UI的WebDriver测试
REST API的集成测试
应用程序服务的集成测试
存储库的集成测试（持久性）
Web控制器的单元测试（REST API）
用于应用程序服务的单元测试
验证器的单元测试
通过集成测试，我的意思是针对在类生产环境上部署的全功能应用程序的测试。对于单元测试，我的意思是针对针对单个类的测试，针对这些类的协作者/依赖项已被测试双打（模拟，存根等）取代。
显然，每个测试都有不同的视角（以用户为中心的Web测试，以API消费者为中心的API测试，以开发者为中心的其他视角），并验证不同的断言（用于Web测试的HTML元素内容，用于API测试的HTTP响应和状态代码） ，应用程序测试的数据库内容和异常，单元测试的极端情况等）。但是所有这些测试之间也有很多重叠之处，尤其是在测试装置方面（例如，如果已经注册了使用相同电子邮件的其他用户，则用户无法注册）。因此，我们可以避免将精力集中在较高的层上来编写其中的一些测试（例如，仅编写Web测试以使用重复的电子邮件案例进行用户注册），但是如果较低层可以被服务层重用，则它们将暴露出来。不同的客户端（例如批处理客户端使用的应用程序服务）。
因此，我们最终想知道编写所有这些测试将多么有用，以及如何使我们的方法更有效率。您对此有何看法？
我意识到，这是一个讨论型问题，而不是具有清晰可验证答案的问题，因此，如果这不是合适的论坛，请您指导我。这些讨论的最佳论坛。
干杯！
#1 楼
编写和维护自动化测试是一项巨大的投资，并且可以缓慢启动编写和维护自动化测试的成本很高。如果以无效方式编写测试，则投资可能无法收回。同样，如果由于测试的编写方式或被测接口的快速变化而导致测试需要大量维护，则您的投资可能无法收回。与任何大笔投资一样，值得简化流程，以便有时间进行试验并从错误中恢复。
自动化的UI测试尤其脆弱，您仍然需要手动进行测试
以我的经验，UI测试往往比API级别的测试更脆弱。浏览器不断发展，在我看来，每个新的浏览器版本都需要对Selenium进行更改，有时还对我的测试进行更改。如果HTML在适当的位置未使用元素ID，则您的测试必须通过不太固定的方式识别元素。
最重要的是，UI的某些方面仍需要人工检查：布局，措辞，颜色，字体和图形的使用以及可用性。
测试是达到目的的一种手段，而不是目的本身
我们的工作既困难又复杂，寻找能够无条件解决问题的绝对答案是很诱人的。但是，每个开发人员和每个项目都是不同的。一些开发人员喜欢快速编码并使用自动化测试来发现错误。其他开发人员在编写一行代码之前可能要花很长时间进行思考，因此犯下的错误更少。只要他们的素质很高，他们的工作方式就没关系。
此外，即使对于同一位开发人员，其工作质量也可能因他们的不同而有所差异。正在努力。
我曾经认为每个人都应该为所有内容编写自动化测试，但是在与不同规模，技能和经验的各种团队合作之后，我认为正确的答案会更加复杂和混乱。
考虑自动编写在任何其他类型的测试都耗时，容易出错和/或重复的情况下进行测试。
某些问题比其他问题更容易进行自动化测试。专注于显然无法通过其他任何方式进行测试的领域，将有助于您在宝贵的时间里进行良好的投资。
相互交流
重复一些工作是不可避免的如果您对测试有雄心壮志，但是可以通过相互谈论您要测试的内容来减少它。
#2 楼
Spiff，您怀疑问题没有万能的答案，但是我可以提供一些建议。
只要有可能，请查看只需对任何特定动作进行一次编码，然后重复使用多次。
尽可能将面向对象和数据驱动的测试代码结合起来进行测试。级别测试和功能测试，请执行以下操作：如果可以以功能的形式编写功能动作以单击链接，然后从文本文件中传递页面，链接信息和预期结果，则您只需要一个单元代码来处理单击链接，并且可以在多个位置使用此链接进行流程测试。组合选择，按钮单击等类似的例程意味着您可以最大程度地减少重复工作。
如果多个测试运行正在应用程序的同一部分，则使数据验证仅是一次运行的一部分。
随时记录测试内容。我正在使用一个脚本代码库，该代码库具有超过一百万行代码，几乎相同数量的数据行，并且执行了如此多的测试用例，如果有任何文档，其中大多数文档的记录都不好。弄清楚哪一点造成了很大的痛苦，以至于其中存在很多重复，并且遗留的影响是噩梦般的。
希望这为您提供了一个不错的起点来考虑。
评论
扩展了这个问题：您知道测试冗余的好坏例子吗？