很好奇人们如何组织模式的集成测试，特别是针对路线，以供新开发人员重用。
TLDR；底部有问题。
我正在进行遗留测试，它们正确遵循1种模式，此后没有一种。
我们做的正确的是，每个用户类型都有特定的类型，我发现这是一些关心此问题的人的建议。这不会改变，因此我只是将其用作元数据。
在测试内部，到处都是测试，具体取决于谁编写测试。
特别是我正在使用javaScript，这没什么大不了的，但是对于一些更有经验的人来说，它也可能很重要。
取决于编写者，编写的时间以及是否有更改，胆量是一团糟。
before通常总是在顶部，通常之后是beforeEach。但是某些文件具有多个before块，这使我大吃一惊，但是重构它可能不值得（此时）。
after基本上位于最底部，但是我可以看到一个非常有效的参数after紧接在before之后。在after不在底部的情况下，不清楚它是否是故意放置的，因为在某些情况下，before和after之间有东西，但从未进行过测试（感谢Odin）。
毕竟，它会变得疯狂。
有时候，测试中存在一条逻辑路径，以线性关系来确定碰到路线时事物如何发生（检查是否设置了参数，验证事物等）。
其他时候，成功的结果是最高的，然后就像是有空的时候写它们的人一样。
然后是其他时候，最后写的测试是第一个还是最后一个。
我非常乐于不让新开发人员对事物进行决策，因此遵循模式是一种有价值的工具。有人争论为什么这没有价值，但是我不想说服它是否有价值，我对其他人的行为特别感兴趣。
因此，在喝咖啡休息时间进行头脑风暴，我想出了一些主意，我很好奇其他人的工作。
TLDR；问题
以下是关于模式的一些想法（是否发现）：
1）事物的线性顺序。
优点：不会有混淆的余地，测试按操作顺序进行。
缺点：从技术上讲，只有按顺序滚动才能确认
2）按结果代码排序。 （因此400、401、404、200、204 ...等） 优点：超级有条理，更容易搜索（代码中有404个代码，404中应该描述多少个测试） 缺点：不能很好地解决问题
3）黄金路径在顶部，然后在下方 优点：一致。...加200次测试可能永远是最长的 缺点：它只比没有模式要好
我还有其他想法，就是我不能给一个更好的专家一个一致的东西，所以这只是在杜绝好主意。
任何支持或反对这些想法的建议，意见将不胜感激。我敢肯定我已经完全忽略了其他想法。