Jest: 期待のための人間が読めるコンテキスト

おい！ そのため、実際にはJasmineでこれを使用していましたが、FBで数千を超えるテストファイルを使用している人は誰もいませんでした。 そのため、今のところ、おおよその情報と期待につながるスタックトレースを含む素晴らしいエラーメッセージを出力しています（スクリーンショットのように）。 スローする行を印刷できることに同意しますが、アサーションは複数行の長さであることがよくあります。

expect(a).toEqual({
  …
});

したがって、これは実際にはあまり見栄えがよくなく、パーサーを使用してJSを解析し、関連情報を抽出する（そして長い行を折りたたむ）などして、見栄えを良くする必要があります。

個人的には今のところ十分な情報を示していると思いますが、再考させていただきます。 それほど複雑ではないが、問題をより迅速に解決するのに役立つコンテキストを追加するアイデアがある場合は、お知らせください。

私たちは実際にこれをジャスミンで持っていましたが、FBで何千ものテストファイルを使用している人は誰もいなかったことがわかりました

@cpojerなので、パターンは各アサーションをitでラップしますか？ および/または単に行番号を信頼しますか？

このパターンが良くも悪くも採用されていない可能性はありますが、既存のテストとの一貫性のためだけに採用されているのでしょうか。 またはおそらく機能が存在することを知らないのですか？ これがジャスミンにあるとは知りませんでした。

スローする行を印刷できることに同意しますが、アサーションが複数行の長さであることがよくあります

1行にリファクタリングすると、アサーションでより多くのセマンティック情報が促進される可能性がありますか？ 多分？

const adminUser = {
  …
}
expect(a).toEqual(adminUser);

個人的には今のところ十分な情報を示していると思いますが、再考させていただきます

上記の例は、すべてに冗長（IMO）ラッパーを追加しない限り、どのアサーションが失敗したかを正確に検出するのが難しいことを示しています。 これは、ソースマップの行番号が常に正確であるとは限らないトランスパイル環境で特に当てはまります。 簡潔なテストと同様に、迅速かつ正確に理解することが壊れた場所と重要な場所であると私は信じています。

それほど複雑ではないが、問題をより迅速に解決するのに役立つコンテキストを追加するアイデアがある場合は、お知らせください。

私は上記のいくつかの提案をしました：

• アサーションメソッドの追加のオプションパラメータ
• 連鎖コンテキストメッセージ

もっとシンプルなもの、または違うものをお探しですか？

ねえ@timoxley！ 私たちはすでにこのようなものを追加することを考えていました。

したがって、最初のオプションの問題は、一部のマッチャーにオプションの引数があり、それが事態をより複雑にすることです。

たとえば、2番目のケースでは、引数が近接であるかエラーメッセージであるかはわかりません。

expect(555).toBeCloseTo(111, 2, 'reason why');
expect(555).toBeCloseTo(111, 'reason why');

何かが期待に合わなくなるとすぐにマッチャーがスローするため、2番目の提案は機能しません

expect(1).toBe(2)/* will throw here */.because('reason');

次のように、マッチャーが実行される前に理由を添付できます。

expect(1).because('reason').toBe(2);
// or 
because('reason').expect(1).toBe(2);

しかし、このAPIはそれほど見栄えがよくありません。

別のオプションは、2番目の引数をexpectに追加することです。

expect(1, 'just because').toBe(2);

ただし、前のオプションとほとんど同じです。

これがあまり役に立たないと思う理由は、エンジニアがテストを書くのに時間を無駄にしたくないからです。 彼らにとってそれを難し​​くするために私たちがすることは、ただより悪いテストにつながるでしょう。

以前は、最善の解決策は実際にはカスタムマッチャーを作成することでした。 次のバージョンのJestでexpect.extendを導入すると、次のようなマッチャーを簡単に作成できるようになります。

expect(a).toEqualMySpecificThing(…)

これにより、より表現力豊かな失敗メッセージを書くことができるはずです。 これはRelayのようなプロジェクトでよく使われています。 すべてのマッチャーを参照してください： https ：//github.com/facebook/relay/blob/master/src/tools/__mocks__/RelayTestUtils.js#L281

活動がないため閉鎖しましたが、良いアイデアがあれば再開してください。

@ cpojer @ dmitriiabramov遅延についてお詫びします。

expectへの2番目の引数、または.becauseで理由を連鎖させるのは素晴らしいことです。 これを実現するために何をする必要がありますか？

エンジニアはテストを書くのに時間を無駄にしたくない

@cpojer同意しました！ テストのデバッグに時間を浪費したくないことに加えて、これがまさに、失敗のコンテキストが多い、冗長性の低いAPIが望ましいと私が信じている理由です。

いくつかの具体的な数値については、上記の私のコメントの簡単な例を使用して、同等のアサーションとテープのコンテキストを取得するために、Jestはプログラマーに儀式の定型文のほぼ2倍の量を書き込むように要求します。

• ラインの1.8倍（6対11）
• インデントの2倍（1対2）
• 括弧/カーリーの2倍（24対48） ！

これは改善される可能性があります！

// tape
test('api works', t => {
  t.deepEquals(api(), [], 'api without magic provides no items')
  t.deepEquals(api(0), [], 'api with zero magic also provides no items')
  t.deepEquals(api(true), [1,2,3], 'api with magic enabled provides all items')
  t.end()
})

// jest
describe('api works', () => {
  test('api without magic provides no items', () => {
    expect(api()).toEqual([])
  })
  test('api with zero magic also provides no items', () => {
    expect(api(0)).toEqual([])
  })
  test('api with magic enabled provides all items', () => {
    expect(api(true)).toEqual([1,2,3])
  })
})

更新：矢印を使用して1行にjestテストを記述できると思います。

// jest
describe('api works', () => {
  test('api without magic provides no items', () => expect(api()).toEqual([]))
  test('api with zero magic also provides no items', () => expect(api(0)).toEqual([]))
  test('api with magic enabled provides all items', () => expect(api(true)).toEqual([1,2,3]))
})

これにより、行が長くなりますが、以前に比較した統計が多少改善されます。

• ラインの0.8倍（6対5）
• インデントの1倍（1対1）
• 括弧/カーリーの1.75倍（24対42）

ただし、行の先頭に改行なしでテストの説明があると、テストの「肉」、つまり実際のアサーションが任意の列の位置に配置されるため、ロジックを視覚的に解析するのが難しくなると思います。

コードを解析することは、テストの説明を読むことよりも重要です。テストの説明は、基本的には単なる栄光のコメントです。 これが、行の先頭に誰もコメントを書かない理由です。たとえば、これはサドマゾヒズムの狂気になります。

/* api without magic provides no items */ expect(api()).toEqual([])
/* api with zero magic also provides no items */ expect(api(0)).toEqual([])
/* api with magic enabled provides all items */ expect(api(true)).toEqual([1,2,3])

理想的には、すべてのアサーションコードが同じ列にきちんと並んでいるので、人間が簡単に解析できます。 この考えに基づいて、 expectの2番目の引数を提案するのではなく、末尾の.because形式を強く選択します。

会話を続けてくれてありがとう。 また、describeブロックも必要ないため、さらに小さくなります。 .becauseは残念ながら機能しません。これは、マッチャーがスローしたときに（ .becauseが呼び出される前に発生する）、名前を抽出する方法がないためです。

次に、各マッチャー関数の最後の引数を使用しますか？

expectの2番目の引数として追加した場合にのみ機能します。
あいまいさのため、すべてのマッチャー関数の最後の引数として追加することはできません。
例えば

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

活動がないため閉鎖しましたが、良いアイデアがあれば再開してください。

@cpojer expect(value).toBe(something, 'because message')のジャスミン（およびその他）の方法が除外されているかどうかは不明ですか？

1つの例は、ステートマシンをテストしているredux-saga / redux-observableのものをテストすることです。 どの状態で失敗したかについての説明的なメッセージがあると非常に役立ちます。 その例は考案されているので、説明も同様です。

@jayphelpsすべてのジャスミンマッチャーを書き直したので、ジャスミンの方法を使用しなくなりました

@dmitriiabramov申し訳ありませんが、私の質問は明確ではありませんでした。 それを行うジャスミンの_方法_は、追加されると判断されましたか？ 彼らが許可するのと同じことをする。

@jayphelpsは前に言ったように、あいまいさのためにすべてのマッチャーで機能するとは限りません。

expect(obj).toHaveProperty('a.b.c', 'is that a reason or a value of the property?');

歌うジェストマッチャーはサードパーティのパッケージで拡張できます私は引数リストを台無しにするのは良い考えではないと思います

最もクリーンなオプションは、おそらくexpectの2番目の引数として使用することです。これは、常に1つの引数を取るためです。

expect(123, 'jest because').toEqual(123);

ただし、APIをオーバーロードするかどうかはわかりません。 Facebookのテストスイートではほとんど使用していません。特別な場合は、新しいテストを定義する方が簡単だと思います。

beforeEach(someSharedSetup);
test('reason or description', () => expect(1).toBe(1));

あと数行です:)

または、別のdescribe()呼び出しに入れることもできます。

@dmitriiabramov厄介なケースは、サガや叙事詩などのステートマシンのように、状態を構築する場合です。各テストには以前の状態の変更が必要であり、それらを分離するには、AFAIKを取得せずに大量の複製が必要です。

it('stuff', () => {
  const generator = incrementAsync();

  expect(generator.next().value).toBe(
    call(delay, 1000)
  );

  expect(generator.next().value).toBe(
    put({ type: 'INCREMENT' })
  );

  expect(generator.next()).toBe(
    { done: true, value: undefined }
  );
});

または、別のdescribe（）呼び出しに入れることもできます。

これを詳しく説明していただけますか？ ネスト記述呼び出しAFAIKはセクションタイトルを分割するためだけのものでしたが、テストは引き続き同時に実行されますか？

テストスイート（ファイル）は同時に実行されますが、 test()呼び出しは実行されません。

私はそのようなものを考え始めています

test('111' () => {
  jest.debug('write something only if it fails');
  expect(1).toBe(2);
});

物になることができます

この議論とこのリポジトリから、私は素晴らしくて意味のあるものは次のようになると思います：

it('has all the methods', () => {
  since('cookie is a method').expect(reply.cookie).toBeDefined();
  since('download is a method').expect(reply.download).toBeDefined();
  since('end is a method').expect(reply.end).toBeDefined();
  // ...
});

使用法はbecauseのものと似ていますが、意味的に意味があります。

これが気に入ったら、 since機能を追加してPRを行うことができるかもしれません。

これを行う簡単な方法を実装してください。 私はあまり頻繁に使用しませんが、特により複雑なテストの場合は、掘り下げずに何が失敗しているかを正確に知ることが役立ちます。

「テストスイートをより単純になるように書き直してください」とは言わないでください。 エンジニアが_writing_テストスイート以上に嫌うのは_rewriting_テストスイートだけです。

私がどこかで見た別の提案は、それがうまくいかない理由の説明とともに、これとまったく同じ問題のどこにあったかを忘れています。 私はおそらく少し眠る必要があります:)

いくつかの簡単な「プロトタイプ」デモが機能するようになりました。今すぐ再帰を実装する必要があります。 これは、グローバル変数の周りにプロキシを使用し、次に各メソッドに使用する薄いラッパーです。 ただし、プロキシは古いブラウザではサポートされておらず、ポリフィルできないため、Jestでは受け入れられない可能性があります。 これは、ラッパーの一般的な構造です。

const since = (text) => {
  return new Proxy(global, {
    get: (orig, key) => {
      return (...args) => {
        try {
          const stack = orig[key](...args);
          return new Proxy(stack, {
            get: (orig, key) => {
              return (...args) => {
                try {
                  const ret = orig[key](...args);

                  // ... implement recursion here

                } catch (err) {
                  console.log('2', key, text, err);
                  throw err;
                }
              }
            }
          });
        } catch (err) {
          console.log('1', key, text, err);
          throw err;
        }
      };
    }
  });
};

3つの現実的なオプションがあります。

• この方法は受け入れられるので、メインのJestライブラリに追加する必要があります。 クリーンアップしてPRを作成します。
• Jestを深く掘り下げて、コアライブラリを変更します。 多くの作業があるので、一部のメンバーがこの問題/方向性について半公式に何かを言うまでは何もしません。
• この方法で終了し、パッケージとして公開します。 簡単に見つけられないので望ましくありません。

編集：実際の動作を確認してください：

describe('Test', () => {
  it('works', () => {
    since('It fails!').expect('a').toEqual('b');
  });
});

自明でないテストがある場合にテスト結果を正気にするためには、期待コンテキストが必要です。 実際のテストは必ずしもそれほど単純ではありません。

カスタムマッチャーを覚えておいてください-それらはマッシングの複雑さを隠します。 しかし、テストが失敗した場合、失敗に関する最大の情報が必要なため、この複雑さを隠すことはあなたが望むことではありません。 期待コンテキストにより、このコンテキストを手動で提供できます。 理想的ではないと思いますが、ある種の自動コンテキストの方が良いでしょうが、それが私が今まで見た唯一の方法です。

何かを壊して失敗した場合、Jestを使用して手動でデバッグするか、ログなどの_変更を追加する必要があります。これは、テストの実行結果を確認するよりもはるかに便利ではありません。
たとえば、ジャスミンでは、失敗についてより理解できるようにコンテキストを印刷することができます。
Javaで最も人気のあるテストフレームワークJUnitにも、まったく同じ機能があります。

間違えた場合は申し訳ありませんが、この機能に対する_技術的な_反論はここにはありません。 そして、「見栄えが悪いので、これを追加すべきではない」などのことはばかげています。

再開できますか？ 上記の@aaronabramovによって提案されたjest.debug()でさえ私に役立ちます。

This:

it('has all the methods', () => {
    since('cookie is a method', () => expect(reply.cookie).toBeDefined());
});

can be supported by adding this:


// setupTestFrameworkScriptFile.js
// http://facebook.github.io/jest/docs/configuration.html#setuptestframeworkscriptfile-string
global.since = (explanation, fn) => {
    try {
        fn();
    } catch(e) {
        e.message = explanation + '\n' + e.message;
        throw e;
    }
};

また、 jasmine-custom-messageは、要求されたものと似ています。

describe('test', function() {
  it('should be ok', function() {
    since(function() {
      return {'tiger': 'kitty'};
    }).
    expect(3).toEqual(4); // => '{"tiger":"kitty"}'
  });
});

これを再開する予定はありますか？ 最近、この問題の重複があったようです。 また、テストが失敗したときにカスタムメッセージを表示したいと思っています。

うーん..これもウィッシュリストに載っているものです。 このスレッドを読んだ後、FacebookでのJestの使用に関する応答を理解でき、自分のワークフローに影響を与えたくないのですが、既存のテストに干渉せず、他のいくつかの人が望んでいる機能を追加する提案がいくつかあります。持っている（私自身を含む）。

2番目の引数がexpect（）またはsince（）形式のいずれかがPRとして受け入れられるには、何が必要ですか？ 私はこれを助けるために少し時間を寄付したいと思っています。

私はスレッドを読んだばかりで、両側に良い議論があります。 @timoxleyが最初に投稿したのと同じ理由で、カスタムエラーメッセージを提供するメカニズムが絶対に必要です。 今、私はこのようなことをしています：

import assert from 'assert'
import chalk from 'chalk'

test('api works', () => {
  assert.deepEqual(
    api(),
    [],
    chalk.red('api without magic provides no items')
  )
  assert.deepEqual(
    api(0),
    [],
    chalk.red('api with zero magic also provides no items')
  )
  assert.deepEqual(
    api(true),
    [1, 2, 3],
    chalk.red('api with magic enabled provides all items')
  )
})

これは実際には非常にうまく機能しますが、赤い色を取得するためにチョークを使用する必要はありません（それ以外の場合は色なしで印刷します）。これをexpectでサポートすることをお勧めします。

私はそれがどのように正直に実装されているかは本当に気にしません。 しかし、他の人がそれを好む場合に備えて、何か他のものをそこに投げ出すためだけに、 sinceに代わるものがあります：

const expectWithMessage = expect.withMessage(
  'api with magic enabled provides all items'
)
expectWithMessage(api(true)).toEqual([1, 2, 3])

// could be rewritten like
expect
  .withMessage('api with magic enabled provides all items')(api(true))
  .toEqual([1, 2, 3])

sinceより良いものが好きかどうかはわかりません。 私は何でも上手です、私は本当にこれが欲しいです:)

ああ、そしてコメントに対処するために：

これがあまり役に立たないと思う理由は、エンジニアがテストを書くのに時間を無駄にしたくないからです。 彼らにとってそれを難し​​くするために私たちがすることは、ただより悪いテストにつながるでしょう。

テストの作成を難しくしたくないことに同意します。 そのため、これは追加の変更になります。 したがって、テストのデバッグを容易にするために「時間を無駄にする」ことを望まない人は、役立つメッセージをスキップできますが、このような役立つメッセージを含むコードベースにアクセスして、感謝します。アサーションを少し説明するのに時間をかけたエンジニア：wink：

こんにちは@cpojerこれに関する更新はありますか？

Jestは、この問題を除いて、私にとってうまく機能しています...現時点では、次のようなforループ内で失敗したアサーションを修正するのに苦労しています。
expectationsArray.forEach(expectation => expect(...))

カスタムエラーメッセージなしでどの期待が失敗するかを正確に把握することは困難です（私が間違っている場合を除きます..？）

ありがとう

@ mj-airwallexたとえば、forループで期待値をtestでラップするのは良いことです。

const expectationsArray = [[0, 'a'], [1, 'b']];

expectationsArray.forEach(([expectation, desc]) => {
  test(`test ${desc}`, () => {
    expect(expectation).toBeGreaterThanOrEqual(2);
  });
});

期待の間にカスタムメッセージを提供する必要があるため、jestにも問題があります。 testで期待値をラップすることは、非同期呼び出しの必要がない場合に機能するようです。 ただし、Jestはdescribe （＃2235）がpromiseを返すことを処理できないため、非同期呼び出しを使用してテストを作成したり、 testでラップしたりすることはできません。 また、複数のtestネストすることはできません。

問題を説明する例を次に示します。

async function getArray() {
  return [0,0,0,0,0,0]
}

describe('Custom messages with async', async () => {
  const array = await getArray();
  array.forEach((item) => {
    test(`test${item}`, () => {
      expect(item).toBe(0)
    });
  });
})

これを処理する方法はありますか？

OPの問題（「どの期待が失敗したかをすぐに明らかにする、人間が読める形式のコンテキストがあればいいのに」）を見ると、これで解決したと思います。 Jest 22の時点で、失敗したアサーションのコンテキストを出力します。 追加のメッセージはまだ必要ですか？ _is_の場合、アサーションの上または横にあるコードコメントである可能性があります

非同期記述は別の問題です（追加されたコードフレームでは解決されません）

私は非同期記述を使用せず、代わりにbeforeEachまたはbeforeAllを使用すると思います

@kentcdoddsは、 beforeEachまたはbeforeAllでこれを処理する方法の例を提供できますか？ 必要なすべての非同期呼び出しの結果をbeforeEachとbeforeAllで作成しようとすると、最終的には、許可されていないネストされたtestを作成する必要があります。

ああ、私はあなたがその非同期呼び出しで何をしていたかを逃しました。 申し訳ありませんが😅ええ、 beforeEachまたはbeforeAllを実行することはできませんでした。

@SimenB 、コンテキストを印刷すると、すでに多くのことが役立ち、カスタムメッセージの問題のほとんどが解決されます。 これをありがとう！ ただし、ループ内でexpectsを使用する場合などの状況で役立つため、カスタムメッセージを引数として明示的に指定できると便利です。

@tojuhakaこれを試してください： https ：//github.com/negativetwelve/jest-plugins/tree/master/packages/jest-plugin-context

OPの問題（「どの期待が失敗したかをすぐに明らかにする、人間が読める形式のコンテキストがあればいいのに」）を見ると、これで解決したと思います。

はい、これは元の問題を解決します。ただし、ほとんどのJestユーザーが持っている、変換前の元のソースにアクセスできる場合に限ります。 IMOは、ユーザーが失敗したユーザー提供のメッセージを印刷できるようにするのに比べて少し手間がかかりますが、十分だと思います。

Jestを使い始めたばかりですが、このような機能がありません。 私のユースケース：
オブジェクトのプロパティが真実であると主張するテストは失敗しています。 アサーションが失敗した場合にオブジェクトをログに記録できれば、失敗をより早く理解するのに役立ちます。

そのためにtoHavePropertyを使用できます。

test('property', () => {
  expect({foo: 'bar'}).toHaveProperty('baz', 'foobar');
});

そこにあることを確認したいだけの場合は、2番目の引数を削除してください。 _some_値があることを表明したいだけの場合は、 expect.anything()を使用できます。
toMatchObjectは別の選択肢です。

必要に応じて、 assertを使用することもできます。

test('property', () => {
  const obj = {foo: 'bar'};
  assert.equal(obj.baz, 'foobar', JSON.stringify(obj));
});

先端をありがとう。 assert.equal(obj.baz, 'foobar', JSON.stringify(obj));は、私の特定のケースでその仕事をします。

@SimenB @mpseidelアサートとは何ですか？ サードパーティのライブラリですか？ jestドキュメントに何も見つかりません。

@sharikovvladislav assertはノードコアモジュールですhttps://nodejs.org/api/assert.html

@mpseidelおっと！ 知りませんでした。 ありがとう。 できます。

次のコードフラグメントを使用して、フレームワークのこの制限をハックしています（TypeScriptでは、JSの型注釈を削除するだけです）
export const explain = (expectation: () => void, explanation: string) => { try { expectation(); } catch(e) { console.log(explanation) throw e; } }

こんにちは、
まだ誰もループについて言及していないことに驚いています。 メッセージは単なる文字列ではなく、ループの反復に応じた動的な文字列になります。
jest-plugin-contextは素晴らしいです、これはうまくいきましたが、少し重く、最初の問題はまだ関連性のあるimoです。
このテストを見てください

describe('MyStuff', () => {
    it('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];
      expectedKeys.forEach((key) => {
        expect(wrapper.find({ id: key }).length).toEqual(1);
      });
    });
  });

あなたの犯人を見つけて頑張ってください。 今のところ、 {len:.., key:..}のように行を追加するか、オブジェクトをテストする必要があります。これはクリーンではなく、ユーザーフレンドリーでもありません。
このユースケースは、たとえばフォームやアイテムのレンダリングチェックに関連していると思います。
構文はtoEqual(1).context("my message")またはtoEqual(1, "my message")のように単純にすることができます（もちろん、実装は常に難しいことを知っています。Jestで行った素晴らしい仕事を尊重します）。

たぶんchaiと同じ形式を使用します-つまり、expect呼び出しの2番目の引数としてメッセージを追加します。

expect(foo, 'this detail').toEqual(2)

T

以前はジャスミンを使用していたので、サポートされていないことを確認するためにここに来ました。
ただし、これらはすべて機能です。 次のようなことだけを行うことはできませんか？

describe('MyStuff', () => {
    describe('should render and contain relevant inputs', () => {
      const wrapper = shallowWrapped(<MyStuff />);
      const expectedKeys = ['love','jest','but','need','details','for','expect'];

      expectedKeys.forEach((key) => {
        it(`contains key "${key}"`, () =>
          expect(wrapper.find({ id: key }).length).toEqual(1)
        )
      })
  });
});

@akkerman素晴らしい解決策。 記述し、それは冗談によって提供される魔法のグローバルであるため、それらがあいまいに感じる可能性があることを認めなければなりません。ループで「t」を書くことがうまくいくかどうかはわかりませんでした。

別の修飾子を連鎖させるのはどうですか？

expect(foo).toEqual(bar).because('reason with %s placeholders')

または多分関数

expect(foo).toEqual(bar).explainedBy((result) => `Lorem ipsum ${result}`)

別の修飾子はすぐに読めなくなると思います。
T

2018-04-19 13:47 GMT + 02：00λ•Geovani de [email protected] ：

別の修飾子を連鎖させるのはどうですか？

expect（foo）.toEqual（bar）.because（ '％sプレースホルダーのある理由'）

または多分関数

expect（foo）.toEqual（bar）.explainedBy（（result）=> Lorem ipsum ${result} ）

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/facebook/jest/issues/1965#issuecomment-382705387 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAM5PwBCvET1KdEDeDEF7gGo708Naj8oks5tqHlSgaJpZM4Kc6Uu
。

-

Tarjei Huse
モービル：920 63 413

expectが機能する方法はスローすることであるため、とにかく機能しません。

expect(something, 'some helpful text on failure').toEqual(somethingElse)またはexpect.context(something, 'some helpful text on).toEqual(somethingElse)のどちらかが最良の選択肢だと思いますが、どちらもあまり好きではありません

これを再開できますか？ Jestには、複数の相互作用で状態がどのように変化するかをテストするための適切なソリューションがまだないようです。たとえば、次のようになります。

• 一連のイベントに応じてステートフルReactコンテナがどのように変化するかをテストする
• Puppeteerを使用して、複数のインタラクションを通じてWebページがどのように変化するかをテストする

これらのケースはどちらも、一連のアクションを実行し、各アクションの後に状態がどのように変化したか（または変化しなかったか）をアサートする必要があるため、マルチアサーションテストが必要になる場合があります。 この種の問題をbeforeEachで解決できるとは限りません。

私はこれが本当に役立つ状況を見つけ続けています。 特に、 @ callumlockeが説明するように、複数のインタラクションとアサーションを実行している場合。

人々が嫌いではないAPIを思いついた場合、これはあなたが進んで追求したいものですか？ これは価値があり、よく使われる機能だと思います。

提案されたソリューションの概要は次のとおりです。

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

expect(api(), 'api without magic provides no items').toEqual([])
expect(api()).because('api without magic provides no items').toEqual([])
since('api without magic provides no items').expect(api()).toEqual([]))
because('api without magic provides no items').expect(api()).toEqual([]))
jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

末尾の.because()は使用できないため、オプションとして含まれていないことに注意してください。

現在、最初のグループの4つのオプションすべてがサポートされています。 個人的には、最初のオプション（コメント付きのコードフレーム）がうまく機能することがわかりました。 そして、それよりもさらに優れているのは、カスタムマッチャー（オプション4）を使用することです。

これを動かすために理解する必要があるのは、最初のグループのオプションよりも2番目のグループのオプションの方が魅力的だと思います。 2番目のグループは、提供するすべてのマッチャー（非同期マッチャー、非対称マッチャー、スパイマッチャー、スローマッチャー、プロミスマッチャー、カスタムマッチャー全体）のコアメンテナンスを正当化できるものを追加しますか？

こんにちは、
基本的に、いくつかのユースケースがあります。

• 複数のアサーションテスト（テストで複数のものをアサーションする必要があります）
• 動的に生成されたアサーションコンテキスト（多くのテストを受けたために失敗したオブジェクトの特定のフィールドを印刷する場合など、失敗メッセージの変数を明確にする必要があります）
• 動的に生成されたアサーション（アサーションを生成するループを作成します）

最初のグループオプションは、主に最初のユースケースを対象としています。 提案されているように、動的に生成されるアサーションが必要な場合は、 itとtestへの呼び出しをネストして、テストがループ内で新しいテストを生成できるようにすることができます。 問題は、アサーションではなくテストを生成することです。 1000要素配列の各要素に何かをアサートしたいと想像してください。これはテストの要約を肥大化させます。

ただし、これらの動的なユースケースはまだまれであるため、メンテナの作業を最小限に抑えるソリューションに固執する必要があります。 私は個人的にbecause/sinceソリューションが好きです。なぜなら、それは非常に単純に聞こえるからです。 実装は、ほとんどの場合、メッセージを出力して返すtry/catchでexpectをラップすることになると思いますか？
jest.debugは奇妙に聞こえますが、テストが実際に合格した場合でも、デバッグはメッセージを出力します。
「最後の引数」オプションも良いですが、 expectは可変数の引数を受け入れることができるので、それが実行可能かどうかはわかりません。

私はどんなオプションでも大丈夫です。 機能が欲しいだけです。 私はjest.debug APIについても大したことはありませんが、それが理にかなっている唯一のAPIである場合は、この機能が必要なだけなので問題ありません。

@kentcdodds既存の4つのオプションはどうですか？

@ eric-burelは、Jest 23（Jest <23のスタンドアロンとして利用可能）にtest.eachとdescribe.eachが追加されているのを見たことがありますか？

私が言ったように、私は私たちがどのオプションを使うかは本当に気にしません。 機能が存在したいだけです。 優先順に並べ替えると、次のようになります。

1. expect(api(), 'api without magic provides no items').toEqual([])
2. because('api without magic provides no items').expect(api()).toEqual([]))
3. since('api without magic provides no items').expect(api()).toEqual([]))
4. expect(api()).because('api without magic provides no items').toEqual([])
5. jest.debug('api without magic provides no items'); expect(api()).toEqual([]))

(test|describe).eachは素晴らしいですが、1回のテストで複数のアクション/アサーションが必要な問題は解決しません。

この機能は現在、次の4つのオプションで存在します。

expect(api()).toEqual([]) // api without magic provides no items
it('api without magic provides no items', () => expect(api()).toEqual([]))
test('api without magic provides no items', () => expect(api()).toEqual([]))
expect(api()).toHaveNoItems()

これらの何が問題になっていますか？ 提案された_新しい_ソリューションは、これらの既存のソリューションよりもわずかに優れているように見えます。 メンテナンスコストを正当化するために、私たちが持っているものにどのようなメリットがありますか？

@rickhanloniiニース私はtest.eachについて知りませんでした、これは本当に素晴らしい機能です、これを指摘してくれてありがとう。 配列から動的に生成されたテストである私の3番目のユースケースの問題は解決すると思います。

そのため、私がリストした2番目のメッセージを残しました。動的に失敗メッセージを生成することで、デバッグが高速化されます。 現在、ユースケースはあまりありません。オブジェクトフィールドの値をテストするときに、失敗したときにオブジェクト全体を印刷したい場合があります。 これは正当なimoであり、わずかなものや少し冗長なものであっても、テストの作成を容易にするものです。 結局のところ、 itとtestの両方を書くことができますが、違いがない限り、これは主に快適さのためです。
このスレッドが示すように、これは限界ですが、実際にはユーザーが期待するもの（しゃれなし）です。

編集： itまたはtestを使用して別のテストでテストを作成し、動的に生成されたテストの名前は有効なソリューションですが、アサーションを作成することを意味する場合、テストを作成するのは本当に好きではありません。 このスレッドで解決策が提供されていなければ、それが可能だとは思いもしませんでした。

狂ってる。 2番目のオプションのパラメーターをexpect（）に追加するだけです。 それを使いたい人は（選択的に）使い、使わない人は使いません。

モカはこれを永遠に続けてきました...それは私が何年も前にジャスミンを放棄した理由の1つです（もう1つはタイマーのモックがはるかに優れています）。他のジャスミン誘導体。

エラー時にメッセージを出力することは、他の多くのテストフレームワークでは慣例であり、Jestに表示されないことに驚きました。 このスレッドで役立つ例をたくさん見つけましたが（それらに感謝します）、テストの失敗時にカスタムエラーを出力する明示的な方法を追加すると、Jestの使いやすさが向上します。 これにより、他のテストフレームワーク（JS以外のフレームワークを含む）に慣れている開発者がJestを簡単に利用できるようになります。

@mattphillipsここでjest-chainに似た何かをして、ユーザーランドにソリューションを存在させることは可能だと思いますか？ たとえば、 expectの2番目の引数

正直なところ、これはほとんどのJSテストフレームワークで非常に標準的なものです。 すべてのテストをカスタムエラーメッセージで記述しているため、Jestで見つからなかったのは非常に残念です。

@SimenB申し訳ありませんが、今朝あなたのメッセージに気づいただけです！

はい、これはユーザーランドで実行可能です。ノックアップしてjest-expect-messageとしてリリースしましたhttps://github.com/mattphillips/jest-expect-message

フィードバック歓迎：smile：

素晴らしい、それをしてくれてありがとう！

@cpojer

これがあまり役に立たないと思う理由は、エンジニアがテストを書くのに時間を無駄にしたくないからです。 彼らにとってそれを難し​​くするために私たちがすることは、ただより悪いテストにつながるでしょう。

2つのこと：

1. オプションの2番目の引数をexpect（）に追加しても、開発者にとって何も難しくなることはほとんどありません。
2. 開発者が最後にやりたいことは、テストが失敗した原因のデバッグに時間を浪費することです。 多くの場合、期待と受信は、条件が満たされているかどうかを確認するための良い方法ですが、多くの場合、条件が失敗した原因について十分なコンテキストがありません。

Jestに来る前に、私はMocha / Chaiとテープを使用しましたが、これは本当に大きな問題です。 カスタムメッセージのサポートを期待するにはどうすればよいですか？

カスタムマッチャーを作成するためにexpect.extendを指定すると、最初の引数で避けようとしていたものとまったく同じように聞こえます。「エンジニアはテストの作成に時間を無駄にしたくない」。

単体テストを開いて行番号を確認するのは簡単なので、OPのユースケースは気になりません。

私を悩ませているユースケースは、テスト内にループがある場合です。たとえば、列挙型のすべての値をテストする場合です。たとえば、次のようになります。

it("Should contain at least one word of every wordType", () => {
  for (const wordType of wordTypes) {
    expect(words.find((word) => word.wordType === wordType)).toBeTruthy();
  }
});

それが失敗した場合、どのwordType値が失敗したかわかりません。

私の回避策は、それをテスト結果を含むメッセージに置き換え、メッセージに期待されるテスト結果が含まれることを期待することでした（つまり、true）。 失敗した場合、Jestは追加情報を含むメッセージを出力します。

    expect(`${wordType} ${!!words.find((word) => word.wordType === wordType)}`).toEqual(`${wordType} ${true}`);

ジェストはこれを印刷します...

expect(received).toEqual(expected)

Difference:

- Expected
+ Received

- 6 true
+ 6 false

...これは、失敗したときにwordTypeが6であったことを示しています。

またはもっと読みやすいように...

    if (!words.find((word) => word.wordType === wordType)) {
      expect(`Didn't find a word with wordType '${wordType}'`).toEqual(null);
    }

@cwellsxは、 test.eachを使用してパラメーター化されたテストをチェックアウトします。これにより、各wordTypeは、（値に基づいて）説明的なタイトルを持つ独立したテストになります。

これは、次のようなテストで非常に役立ちます。

test("compare ArrayBufferCursors", () => {
    const orig: ArrayBufferCursor;
    const test: ArrayBufferCursor;

    expect(test.size).toBe(orig.size);

    while (orig.bytes_left) {
        expect(test.u8()).toBe(orig.u8());
    }
});

今のところ、ArrayBufferCursorの一部のバイトが間違っていることしかわかりませんが、どれが間違っているのかわかりません。 コンテキストとしてインデックスを追加できると、デバッグがはるかに簡単になります。 ありがたいことに、ここで回避策を提示した人もいますが、それらはすべて醜くて遅いです。

@ rickhanlonii 、jestのメンテナンスコストを削減したいとのことですが、コメントで提供するオプションにより、他のすべてのプロジェクトの単体テストのメンテナンスが増加します。 toEqualを使用してアサーションを説明したい場合、それ以外の点では完全に十分ですが、カスタムマッチャーを導入することを本当に提案していますか？！

it.eachが役立つ反復テストの場合もありますが、アサーションに関する単純なコメントに不要なコードを追加する必要があるため、このテストフレームワークの使用が難しくなります。

この議論とjest-expect-messageの出現は、ジャスミンのbeforeAllの問題について思い出させてくれます...

ここでOPの要求を誤解している可能性がありますが、解決しようとしてこの問題のスレッドにたどり着いた問題は、単純なtry / catchとjest.expectのラッパーを使用するだけで解決されました。 私がやりたかったのは、私が期待したオブジェクトと受け取ったオブジェクトの全体と、その重要性を説明するいくつかの基本的なログを記録することだけでした。 もちろん、これを拡張して、ほぼすべてのことを実行できます。

これの最も一般的なバージョンは次のようになります。

in some test utility file...

const myExpect = (expectFn, errorCallback) => {
  try {
    expectFn();
  } catch (err) {
    errorCallback();
    throw new Error(err);
  }
};

// in the actual test suite...

const context = { hello: "world", results, expected };
myExpect(
    () => expect(results).toEqual(expected),
    () => console.error("[Error] -- context:", JSON.stringify(context))
);

+1
こんにちは、私もこの機能が大好きです。 それは私の人生をとても楽にしてくれるでしょう。