您可以放心地假设单个文件中的测试将按照出现的顺序运行。您可以通过在每个it块中放置一个console.log来证明这一点。
可能值得一提的是，依赖于执行/外部状态的顺序通常是不好的做法......你永远不知道，Jest（或当前底层测试运行器Jasmine）可能会决定在新版本中以随机顺序运行它们。

2020年的笑话

要添加更多信息，async测试在describe()语句中以 * 系列 * 运行。这对于IO/数据库设置和清理功能很有用。看看下面的例子：
some.spec.js

describe("my asynchronous tests", () => {
  beforeEach(async () => {
    console.log('> setup test')
    // SOMETHING ASYNCHRONOUS
  });
  afterEach(async () => {
    console.log('< teardown test')
    // SOMETHING ASYNCHRONOUS
  });

  test("test 1", async () => {
    console.log('-- starting test 1');
    // SOMETHING ASYNCHRONOUS
    console.log('-- finished test 1');
  }, 100000);

  test("test 2", async () => {
    console.log('-- starting test 2');
    // SOMETHING ASYNCHRONOUS
    console.log('-- finished test 2');
  }, 100000);
});

输出：

> setup test
-- starting test 1
-- finished test 1
< teardown test
> setup test
-- starting test 2
-- finished test 2
< teardown test

多个describe()语句将并行执行，即使它们在同一个文件中。

注意，如果两个测试中的一个在5秒后超时，您可能会得到并行运行的两个测试的副作用- jest停止等待超时的测试，但它的代码继续执行，与以下测试jest并行。
（在我意识到这是导致我来到这里的副作用的原因之前，拔出了相当多的头发）

如果你想在一个文件中并行运行它们，你可以使用test.concurrent('test run concurrently', () => { ... })，这太慢了。这是一个有点bug，没有很好的记录，但至少有一个方法。
我注意到的一件事是它不会在beforeAll()中等待async的东西，所以你需要一些你自己的技巧（比如setInterval等待）来让它按预期工作。

使用-i或--runInBand标志使测试文件按顺序运行

jest --runInBand

ref：jest docs
奇怪的是，在我的M1 Mac上按顺序运行测试完成得更快！，更好地测试您的用例

一些额外的信息@Klesun回答。我们可以重复以下步骤

test('first test', async () => {
    console.error('first test before waitFor');
    try {
        await waitFor(async () => { throw new Error(''); }, { timeout: 6000 });
    } catch (e) { }
    console.error('first test after waitFor');
}, 5000);

test('second test', async () => {
    console.error('second test before timeout');
    await new Promise((r) => setTimeout(r, 6100));
    console.error('second test after timeout');
}, 6200);

其中输出将是：

first test before waitFor
second test before timeout
first test after waitFor
second test after timeout

从第二个测试中删除setTimeout将隐藏“first test after waitFor”，因为该文件的测试将完成。
此外，这导致故障的真正原因在某种程度上被隐藏。例如，如果我们删除try ... catch，那么向我们报告的唯一内容将是test('first test', async () => {的thrown: "Exceeded timeout of 5000 ms for a test.，而不是确切的点（在本例中为waitFor）。在运行时间较长的测试中跟踪这一点可能有点麻烦。我希望在这些情况下跟踪错误所在的最佳途径是增加测试超时。