我知道，在测试自动化中，我们必须avoid sequential test-cases。因此，运行测试用例的顺序并不重要。
我相信在某些情况下，顺序测试用例是不可避免的：
1。考虑一个场景，用户需要采取一些先前的步骤才能完成最终目标。例如，用户需要登录才能购买。
Given User is logged in
When User adds an item into its basket
And User Complete his purchase
Then He receives an Email
因此，在上述情况下，每个部分（Given，When，And或Then）都是单独的测试用例。但是，测试用例的顺序仍然至关重要。
2。此外，Junit团队提供了一种称为@FixMethodOrder(MethodSorters.NAME_ASCENDING)的方法来使用这种方法，但是我不确定何时可以使用它？
那么，您如何在端到端测试中编写独立的测试用例？
答案 0 :(得分：2)
在不应该依赖于先前测试所生成的状态的意义上，测试是原子的。这就是为什么应该避免顺序测试用例的原因。万一序列的任何部分失败了，那么其余的测试也会失败，因此将它们分开实际上并没有多大意义（它们可能只是一个测试）。
如果您在测试中需要先决条件，则可以将其包括在：1）所有测试之前，2）在测试套件开始时，3）在特定测试之前，4）在特定测试内部。无论在何处/何时完成此操作，重要的是您都假定生成状态所需的所有功能均按预期工作，因此您只需关注要测试的内容即可。
现在，如果要测试系统的完整流程，我建议您将其放入一个唯一的测试中。如果有变化，那么您将有多个测试。
例如，假设您要测试D，但是D需要C，然后C需要B，最后B需要A；一种策略是生成一个测试，其中您将执行A-> B-> C-> D。另一种策略是生成多个测试，其中您将测试各个步骤：测试1执行A；测试2执行A-> B（但不在乎A是否可以通过）；测试3执行A-> B-> C（但不在乎A和B是否正常）；等等。使用哪种策略将取决于您的目标和方案的大小。对于大件事情，我个人更喜欢第二种选择，对于简单/短件，我更喜欢第一种。
答案 1 :(得分：0)
espresso UI测试框架允许实现这种核心用户旅程场景。
如果要进行单元测试，则应在每个条件的开头设置预期的前提条件。
答案 2 :(得分：0)
“避免顺序测试用例”的说法仅适用于单元测试。这就是Junit和Mockito发光的地方。在这种情况下，我们只担心单位的正确性。我们不在乎其他单元是否通过测试或失败，我们将模拟其他单元的行为，以便我们可以专注于测试当前测试的确切行为。
您描述的情况不属于此类。在您的情况下，您需要集成测试套件，因为您需要测试端到端流程。您可以使用以下工具进行集成测试。