上下文：在项目上（后端和集成测试中的C＃/ .Net，前端的TypeScript / React）我有更复杂的集成测试，更像是“测试场景”：他们测试业务通过UI的逻辑并以某种方式测试UI的功能，例如：它确保在页面中完成一些修改后，只读取输入字段。
我主要对这些测试有两个问题：
大多数测试描述了一个场景，但由于某种原因，测试框架被设计为代表前端页面上的内容。例如，测试可能会转到版本的表单页面，然后单击“附件”选项卡以获取附件面板，然后单击一下以上载文件。
为此，我被要求修改工作前端，在集成测试应该点击的元素上添加“data-id”属性。我不能说为什么但这对我来说听起来不对。感觉就像我要将集成测试的代码（甚至是简单的）引入前端应用程序。
所以我的第一个问题是：每个人通常如何找到他们的DOM元素？
我担心的是，如果我实际上使用xpath或CSS选择器查找元素，我将最终使用对前端生成的DOM具有强依赖性的测试，而使用data-id可能会使其更加灵活。因此，如果您决定更改元素的位置，您将轻松破坏集成测试。
另一方面，我觉得测试对他们正在做的事情描述得有点好，例如他们应该从3步逻辑Go to attachments > Select file > Click add attachment简化为单步逻辑{{1为了将这个逻辑放在一个地方。
我们有后端单元测试，前端单元测试和集成测试。集成测试的数量比其余部分多2或3倍。而且我不确定我们是否在这些集成测试中使用了正确的东西。
例如，所有不同的登录方法都通过集成测试进行测试。帐户/错误密码锁定机制也通过集成测试进行测试。我们根本没有/需要进行单元测试，大部分时间他们都觉得与集成测试重复。
为了进一步了解这个例子，我认为帐户/错误密码锁定的逻辑应该通过单元测试进行测试，而集成测试应该只检查需要与外部服务集成的登录方法（例如使用Windows凭据）或OAuth）。
但我不知道我究竟会把它放在哪里。所以我的问题是：如何确定测试是属于集成测试还是后端/前端单元测试？你应该问自己一个问题清单吗？
关于这个主题的一些有趣的阅读：Frontend testing: what and how to test, and what tool to use? 特别是：
不要为每个小角落案件编写测试。这些测试编写起来很昂贵，而且运行时间太长。您应该专注于探索大部分功能的案例。如果你在这个级别编写太多测试，你可能会测试你之前在单元测试中测试的相同功能（假设你已经编写过）。