Expect
テストを作成する時に、値が特定の条件に合致することを確認する必要がよくあるでしょう。 expect
によって様々な事柄を検証するための数多くの"マッチャ"を利用することができます。
Jest コミュニティによってメンテナンスされている追加の Jest マッチャーについては、 jest-extended
をご覧ください。
#
メソッドexpect(value)
expect.extend(matchers)
expect.anything()
expect.any(constructor)
expect.arrayContaining(array)
expect.assertions(number)
expect.hasAssertions()
expect.not.arrayContaining(array)
expect.not.objectContaining(object)
expect.not.stringContaining(string)
expect.not.stringMatching(string | regexp)
expect.objectContaining(object)
expect.stringContaining(string)
expect.stringMatching(string | regexp)
expect.addSnapshotSerializer(serializer)
.not
.resolves
.rejects
.toBe(value)
.toHaveBeenCalled()
.toHaveBeenCalledTimes(number)
.toHaveBeenCalledWith(arg1, arg2, ...)
.toHaveBeenLastCalledWith(arg1, arg2, ...)
.toHaveBeenNthCalledWith(nthCall, arg1, arg2, ....)
.toHaveReturned()
.toHaveReturnedTimes(number)
.toHaveReturnedWith(value)
.toHaveLastReturnedWith(value)
.toHaveNthReturnedWith(nthCall, value)
.toHaveLength(number)
.toHaveProperty(keyPath, value?)
.toBeCloseTo(number, numDigits?)
.toBeDefined()
.toBeFalsy()
.toBeGreaterThan(number | bigint)
.toBeGreaterThanOrEqual(number | bigint)
.toBeLessThan(number | bigint)
.toBeLessThanOrEqual(number | bigint)
.toBeInstanceOf(Class)
.toBeNull()
.toBeTruthy()
.toBeUndefined()
.toBeNaN()
.toContain(item)
.toContainEqual(item)
.toEqual(value)
.toMatch(regexp | string)
.toMatchObject(object)
.toMatchSnapshot(propertyMatchers?, hint?)
.toMatchInlineSnapshot(propertyMatchers?, inlineSnapshot)
.toStrictEqual(value)
.toThrow(error?)
.toThrowErrorMatchingSnapshot(hint?)
.toThrowErrorMatchingInlineSnapshot(inlineSnapshot)
#
Referenceexpect(value)
#
expect
は値をテストしたい時に毎回使用する関数です。 expect
のみを呼び出すということはほとんどありません。 代わりに、 値について何らかの事をアサートする"マッチャ"関数とともにexpect
を使用することでしょう。
この事は例を見れば簡単に理解できます。 'grapefruit'
という文字列を返すはずのbestLaCroixFlavor()
メソッドがあるとしましょう。 以下のようにテストするでしょう:
このケースでは、 toBe
がマッチャ関数です。 様々な事をテストするのを手助けする数多くの異なるマッチャ関数があり、以下にまとめられています。
expect
への引数はコードが生成する値であるべきであり、いかなるマッチャへの引数は正解の値であるべきです。 それらを混同して使用すれば、テストは動作するものの、失敗したテストから出力されるエラーメッセージはおかしなものになります。
expect.extend(matchers)
#
Jestに独自のマッチャを追加したい場合は expect.extend
を使用します。 たとえば、数値に関するユーティリティのライブラリをテストしていて、ある数値が他の数値の特定の範囲内に現れることを頻繁にアサートしているとします。 それを toBeWithinRange
のマッチャーに抽象化できます:
注: 例えばTypeScript で @types/jest
を使用する場合は、以下のように新しい toBeWithinRange
マッチャを宣言できます。
#
非同期マッチャexpect.extend
は非同期のマッチャもサポートします。 非同期のマッチャは Promise を返すため、返り値を await する必要があります。 マッチャの一例を使って、使い方を見てみましょう。 We are going to implement a matcher called toBeDivisibleByExternalValue
, where the divisible number is going to be pulled from an external source.
#
独自のマッチャ APIマッチャは、2つのキーを持つオブジェクト (またはオブジェクトのプロミス) を返さなければなりません。 pass
キーはマッチャの条件に合致するかどうかを示し、 message
キーは失敗した場合にエラーメッセージを返す引数なしの関数を提供します。 したがって、pass
が偽なら、 message
はexpect(x).yourMatcher()
が失敗した場合のエラーメッセージを返す必要があります。 pass
が真だった場合、 message
はexpect(x).not.yourMatcher()
が失敗した場合のエラーメッセージを返す必要があります。
Matchers are called with the argument passed to expect(x)
followed by the arguments passed to .yourMatcher(y, z)
:
マッチャがアサーションを反転させる否定の修飾子 .not
を付けて呼ばれたかどうかを示す真偽値で、明確で正しいマッチャのヒントを表示することに利用されます(サンプルコードを参照)。
this.isNot
#
明確で正しいマッチャのヒントを表示するための文字列です:
this.promise
#
2つのオブジェクトが同じ値を(再帰的に) 持つ場合に true
を返す深い等価関数です。
'rejects'
:マッチャが.reject
修飾子付きで呼び出された場合'resolves'
マッチャが.resolves
修飾子付きで呼び出された場合''
マッチャがpromise修飾子付きで呼び出されなかった場合
this.equals(a, b)
#
2つのオブジェクトが同じ値を(再帰的に) 持つ場合に true
を返す深い等価関数です。
this.expand
#
このマッチャが expand
オプション付きで呼び出されたことを示す真偽値です。 Jestが--expand
フラグ付きで呼びされた場合、Jestが全ての差分とエラーを表示することを期待されているかを確認するのに、this.expand
が利用できます。
this.utils
#
jest-matcher-utils
からexportされたもので主に構成されるthis.utils
から利用できる多数の便利なツールがあります。
最も有用なものにエラーメッセージを見やすくフォーマットする matcherHint
、 printExpected
そしてprintReceived
があります。 例えば、 toBe
マッチャの実装を見てみましょう:
上記のコードはこのような出力をします:
アサーションに失敗した場合、エラーメッセージは利用者がその問題を迅速に解決できるようになるべく多くのシグナルを与えるものであるべきです。 独自アサーションの利用者が良い開発体験を得られるよう正確なエラーメッセージを作成する必要があります。
#
Custom snapshot matchersTo use snapshot testing inside of your custom matcher you can import jest-snapshot
and use it from within your matcher.
.toMatchTrimedSnapshot(length)
は指定された長さに文字列をトリムするスナップショットマッチャです :
Jest needs additional context information to find where the custom inline snapshot matcher was used to update the snapshots properly. ただし、インラインスナップショットは常に最初の引数に追加しようとします。 最初の引数がプロパティのマッチャである場合は、2番目の引数に追加しようとします。
expect.anything()
#
expect.anything()
は、null
または undefined
を除くものすべてに一致します。 toEqual
または toBeCalledWith
の内側でリテラル値の代わりに使用できます。 例えば、モック関数がnullでない引数を与えられて呼び出されたことを確認するには:
expect.any(constructor)
#
expect.any(constructor)
は与えられたコンストラクタで生成されたもの全てに一致します。 toEqual
または toBeCalledWith
の内側でリテラル値の代わりに使用できます。 例えば、モック関数が数字の引数を与えられて呼び出されたことを確認するには:
expect.arrayContaining(array)
#
expect.arrayContaining(array)
は受け取った配列が期待される配列の要素全てを含む場合に一致します。 つまり受け取った配列は期待される配列を 包含 するということです。 したがって受け取る配列が期待される配列に含まれない要素を含んでいても一致します。
以下のケースでリテラル値の代わりに使用できます:
toEqual
またはtoBeCalledWith
の中objectContaining
またはtoMatchObject
のプロパティとマッチさせる場合
expect.assertions(number)
#
expect.assertions(number)
はテスト中に特定の数だけアサーションが呼び出されたことを確認します。 非同期のコードをテストにおいて、コールバック中のアサーションが実際に呼ばれたことを確認する際にしばしば便利です。
例えば、 callback1
と callback2
の2つのコールバックを受けとるdoAsync
関数があったとしたら、その関数は未知の順序で両方を呼び出します。 以下のコードでテストできます:
expect.assertions(2)
を呼び出すことで両方のコールバックが実際に呼ばれたことを確認できます。
expect.hasAssertions()
#
expect.hasAssertions()
はテスト中で少なくとも1回はアサーションが呼び出されたことを確認します。 非同期のコードをテストにおいて、コールバック中のアサーションが実際に呼ばれたことを確認する際にしばしば便利です。
例えば状態を取り扱ういくつかの関数があったとしましょう。 prepareState
は状態オブジェクトとともにコールバックを呼び出し、validateState
はその状態オブジェクトを確認し、 waitOnState
はprepareState
のコールバックが完了するまで待つpromiseを返します。 以下のコードでテストできます:
expect.hasAssertions()
は prepareState
のコールバックが実際に呼ばれたことを確認します。
expect.not.arrayContaining(array)
#
expect.not.arrayContaining(array)
matches a received array which does not contain all of the elements in the expected array. つまり、期待される配列は、受け取った配列の部分集合ではないということです。
これは expect.arrayContaining
の逆です。
expect.not.objectContaining(object)
#
expect.not.objectContaining(object)
がマッチするのは、受け取ったオブジェクトが、期待されたどんなプロパティにも再帰的にマッチしない時です。 つまり、期待されたオブジェクトは、受け取ったオブジェクトの部分集合ではない、ということです。 したがって受け取ったオブジェクトが期待されるオブジェクトに含まれないプロパティを含んでいても一致します。
これは expect.objectContaining
の逆です。
expect.not.stringContaining(string)
#
expect.not.stringContaining(string)
matches the received value if it is not a string or if it is a string that does not contain the exact expected string.
これは expect.stringContaining
の逆です。
expect.not.stringMatching(string | regexp)
#
expect.not.stringMatching(string | regexp)
matches the received value if it is not a string or if it is a string that does not match the expected string or regular expression.
これは expect.stringMatching
の逆です。
expect.objectContaining(object)
#
expect.objectContaining(object)
は期待されたプロパティに再帰的に一致する、いかなる受け取ったオブジェクトにも一致します。 つまり期待されるオブジェクトは受け取ったオブジェクトの 一部分 であるということです。 Therefore, it matches a received object which contains properties that are present in the expected object.
期待されるオブジェクトのプロパティにリテラル値を設定する代わりに、expect.anything()
などのマッチャを使用することができます。
例えば、onPress
関数がEvent
オブジェクトと共に呼ばれ、eventが event.x
とevent.y
プロパティを持っていることだけ確認できれば良いと考えましょう。 以下のようにできます:
expect.stringContaining(string)
#
expect.stringContaining(string)
matches the received value if it is a string that contains the exact expected string.
expect.stringMatching(string | regexp)
#
expect.stringMatching(string | regexp)
matches the received value if it is a string that matches the expected string or regular expression.
以下のケースでリテラル値の代わりに使用できます:
toEqual
またはtoBeCalledWith
の中arrayContaining
の要素とマッチさせる場合objectContaining
またはtoMatchObject
のプロパティとマッチさせる場合
この例ではexpect.arrayContaining
内のexpect.stringMatching
によって、複数の非対称なマッチャをネストする方法も示します。
expect.addSnapshotSerializer(serializer)
#
expect.addSnapshotSerializer
を使用して、アプリケーション独自のデータ構造をフォーマットするモジュールを追加することができます。
個々のテストファイルにおいては、JavaScriptに組み込みの型やReactの要素のデフォルトのスナップショットのシリアライザよりもsnapshotSerializers
設定で追加されたモジュールが優先され、それらの全てのモジュールより(このAPIで) 追加されたモジュールは優先されます。 最後に追加されたモジュールが最初に確認されるモジュールになります。
snapshotSerializer
設定に追加する代わりに、個々のテストファイルにスナップショットシリアライザを追加する場合:
- 依存関係を暗黙的でなく明示的なものにしてください。
- create-react-appが利用できなくなるような設定は避けてください。
詳細については configuring Jest を参照してください。
.not
#
何かをテストする方法が分かっているなら、 .not
によってその反対の事をテストできます。 例えば以下のコードでは、ラクロワ飲料で一番美味しいのはココナッツ味ではないことをテストでします。
.resolves
#
追加のマッチャをチェーンするためにに完了したpromiseの値を取り出すにはresolves
を使用して下さい。 promiseがrejectされた場合はアサーションは失敗します。
例えば、以下のコードではpromiseが完了した結果の値が'lemon'
であることをテストします:
Promise をテストしているので、テストはいまだ非同期であることに注意して下さい。 このために、ラップされていないアサーションを返すことで、Jest に処理が完了するまで待つように伝える必要があるのです。
また、async/await
を.resolves
と組み合わせて使うことができます。
.rejects
#
追加のマッチャをチェーンするためににrejectされたpromiseの理由を取り出すには .rejects
を使用して下さい。 promiseが完了した場合はアサーションは失敗します。
例えば、このコードは Promise が理由'octopus'
付きで reject された事をテストします:
Promise をテストしているので、テストはいまだ非同期であることに注意して下さい。 このために、ラップされていないアサーションを返すことで、Jest に処理が完了するまで待つように伝える必要があるのです。
また、async/await
を.rejects
と組み合わせて使うことができます。
.toBe(value)
#
プリミティブ値を比較したり、オブジェクトインスタンスの参照IDを確認したりするには、 .toBe
を使用します。 It calls Object.is
to compare values, which is even better for testing than ===
strict equality operator.
例えば以下のコードでは can
オブジェクトのいくつかのプロパティを検証します。
浮動小数点数に .toBe
を使用しないでください。 例えば、JavaScriptでは数値の丸めによって0.2 + 0.1
と 0.3
は厳密には等価ではありません。 浮動小数点がある場合は、代わりに.toBeCloseTo
を使用してください。
.toBe
マッチャー は 参照IDをチェックしますが、アサーションが失敗した場合、 値の再帰的な比較を 報告します。 特にレポートが大きい場合には、プロパティ間の差分は、テストが失敗する理原因を解明することに寄与しません。 そうすると、比較処理を expect
関数の中に移すことでしょう 例えば、要素が同じインスタンスであるかどうかをアサートするには、次のようにします。
- rewrite
expect(received).toBe(expected)
asexpect(Object.is(received, expected)).toBe(true)
- rewrite
expect(received).not.toBe(expected)
asexpect(Object.is(received, expected)).toBe(false)
.toHaveBeenCalled()
#
次の別名でも同様となります: .toBeCalled()
モック関数が呼ばれたかを確認するには.toHaveBeenCalled
を使用して下さい。
For example, let's say you have a drinkAll(drink, flavour)
function that takes a drink
function and applies it to all available beverages. You might want to check that drink
gets called for 'lemon'
, but not for 'octopus'
, because 'octopus'
flavour is really weird and why would anything be octopus-flavoured? このテストスイートでテストすることができます:
.toHaveBeenCalledTimes(number)
#
次の別名でも同様となります: .toBeCalledTimes(number)
モック関数が期待した回数だけ呼ばれたことを確認するには.toHaveBeenCalledTimes
を使用して下さい。
例えばdrink
関数を引数に取って渡された飲み物の配列に適用する drinkEach(drink, Array<flavor>)
関数があるとしましょう。 drink関数が正しい回数だけ呼ばれたことを確認したいでしょう。 このテストスイートでテストすることができます:
.toHaveBeenCalledWith(arg1, arg2, ...)
#
次の別名でも同様となります: .toBeCalledWith()
モック関数が特定の引数を与えられて呼び出されたことを確認するには .toHaveBeenCalledWith
を使用して下さい。
例えば register
関数で飲み物を登録でき、applyToAll(f)
は 関数f
を全ての登録された飲み物に適用するものとしましょう。 この振る舞いを確認するコードは、下記のように書けるでしょう:
.toHaveBeenLastCalledWith(arg1, arg2, ...)
#
次の別名でも同様となります: .lastCalledWith(arg1, arg2, ...)
モック関数がある場合は .toHaveBeenLastCalledWith
を使用して、最後の呼び出しがどんな引数を渡されたかをテストすることができます。 例えば 複数の風味に対して関数f
を適用するapplyToAllFlavors(f)
関数があり、関数fが最後に操作した風味が'mango'
だったとしましょう。 以下のようにテストコードを書くことができます。
.toHaveBeenNthCalledWith(nthCall, arg1, arg2, ....)
#
次の別名でも同様となります: .nthCalledWith(nthCall, arg1, arg2, ...)
あるモック関数があるとき、.toHaveReturned
を使用すると、モック関数が正しく (つまり、例外が発生せずに) 変えることをテストできます。 たとえば、true
を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
注意: n 番目の引数は1から始まる正の整数でなければなりません。
.toHaveReturned()
#
次の別名でも同様となります: .toReturn()
あるモック関数があるとき、.toHaveReturned
を使用すると、モック関数が正しく (つまり、例外が発生せずに) 変えることをテストできます。 たとえば、true
を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
.toHaveReturnedTimes(number)
#
次の別名でも同様となります: .toReturnTimes(number)
モック関数がちょうど指定した回数だけ正しく (つまり、例外が発生せずに) 返ったことを確認するには、.toHaveReturnedTimes
を使用してください。 例外が発生したモック関数の呼び出しは、関数の返した回数としてカウントされません。
たとえば、true
を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
.toHaveReturnedWith(value)
#
次の別名でも同様となります: .toReturnWith(value)
モック関数が特定の値を返すことを確認するには、. toHaveReturnedWith
を使用してください。
たとえば、飲まれた飲み物 (beverage) の名前を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
.toHaveLastReturnedWith(value)
#
次の別名でも同様となります: .lastReturnedWith(value)
モック関数が最後に返した値が特定の値であるかどうかをテストするには、.toHaveLastReturnedWith
を使用してください。 モック関数の最後の呼び出しで例外が発生した場合、期待した値としてどんな値を指定したとしても、このマッチャは無条件に失敗します。
たとえば、飲まれた飲み物 (beverage) の名前を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
.toHaveNthReturnedWith(nthCall, value)
#
次の別名でも同様となります: .nthReturnedWith(nthCall, value)
モック関数が n 回目に返した値が特定の値であるかどうかをテストするには、.toHaveNthReturnedWith
を使用してください。 モック関数の n 回目の呼び出しで例外が発生した場合、期待した値としてどんな値を指定したとしても、このマッチャは無条件に失敗します。
たとえば、飲まれた飲み物 (beverage) の名前を返すモック関数 drink
があるとすると、テストは次のように書くことができます。 以下のようにテストコードを書くことができます。
注意: n 番目の引数は1から始まる正の整数でなければなりません。
.toHaveLength(number)
#
オブジェクトが.length
プロパティを持ち、特定の数値であるかを確認するには、.toHaveLength
を使用して下さい。
配列や文字列のサイズを確認するのに特に便利です。
.toHaveProperty(keyPath, value?)
#
オブジェクトの指定された参照keyPath
のプロパティが存在するかを確認するには、.toHaveProperty
を使用して下さい。 オブジェクト内で深くネストされたプロパティをチェックするには、 深い階層を参照するために、 ドット表記や keyPath を含む配列を使用することができます。
You can provide an optional value
argument to compare the received property value (recursively for all properties of object instances, also known as deep equality, like the toEqual
matcher).
次に示す例ではネストされたプロパティを含む houseForSale
オブジェクトを含んでいます。 ここでは、オブジェクト内の様々なプロパティの存在と値をチェックするために、toHaveProperty
を利用しています。
.toBeCloseTo(number, numDigits?)
#
toBeCloseTo
では、浮動小数点数を近似的な等価性で評価します。
オプションのnumDigits
引数は小数点以下の桁数の上限を設定します。 デフォルト値 2
の場合、テスト条件は Math.abs(expected - received) < 0.005
以内 (つまり、 10 ** -2 / 2
)となります。
なぜなら、10 進数(ベース 10)での計算は、限られた精度の二進数(ベース 2)での表現による丸め誤差を含んでいることがよくあるからdす。 例えば、このテストは失敗します:
JavaScriptでは0.2 + 0.1
は実際には 0.30000000000000004
なのでこのテストは失敗します。
例えば、このテストは小数点以下5桁の精度で合格します。
toBeCloseTo
が解決すべきなのは浮動小数点におけるエラーなので、大きな整数値はサポートされていません。
.toBeDefined()
#
変数が undefined ではないことを検証するには、.toBeDefined
を使用します。 例えば、fetchNewFlavorIdea()
関数が 何らかの値 を返すことを検証するには、以下のように記述します:
expect(fetchNewFlavorIdea()).not.toBe(undefined)
とも書くことができますが、undefined
を直接コード内で参照するのは避けたほうが実務上良いでしょう。
.toBeFalsy()
#
値がどのようなものかを気にせず、真偽値のコンテクストの中で値が偽であることを確認したい場合は.toBeFalsy
を使用して下さい。 例えば、以下のようなアプリケーションコードがあったとします:
getErrors
がどんなものを返すかは特に気にしないでしょう - false
、null
、あるいは 0
を返すかもしれませんが、それでもコードは動作します。 だからラクロワ飲料を飲んだ後でエラーが無いことをテストしたければ、このように書くことができます:
JavaScriptでは、偽と類推される6つの値があります: false
、 0
、 ''
、 null
、 undefined
、 そして NaN
です。 他の全ては真と類推されます。
.toBeGreaterThan(number | bigint)
#
toBeGreaterThan
により、 実際値 > 期待値
の条件でnumber型またはbigint 型の数値を比較します。 例えば、 ouncesPerCan()
が 10 オンスより大きい値を返すことをテストします。
.toBeGreaterThanOrEqual(number | bigint)
#
toBeLessThanOrEqual
を使用して、 実際値 <= 期待値
の条件でnumber型またはbigint 型の数値を比較します。 例えば、 ouncesPerCan()
が12 オンス以下の値を返すことをテストします。
.toBeLessThan(number | bigint)
#
toBeLessThan
を使用して、実際値 < 期待値
の条件でnumber型またはbigint 型の数値を比較します。 例えば、 ouncesPerCan()
が 20 オンス未満の値を返すことをテストします。
.toBeLessThanOrEqual(number | bigint)
#
toBeGreaterThanOrEqual
を使用して、 実際値 >= 期待値
の条件でnumber型またはbigint 型の数値を比較します。 例えば、 ouncesPerCan()
が12 オンス以上の値を返すことをテストします。
.toBeInstanceOf(Class)
#
オブジェクトがクラスのインスタンスであることを確認するには .toBeInstanceOf(Class)
を使用して下さい。 このマッチャは instanceof
を内部で利用しています。
.toBeNull()
#
.toBeNull()
は .toBe(null)
と同じですが、エラーメッセージが少し分かりやすいものになっています。 そのため何かがnullであることを確認したい場合は .toBeNull()
を使用して下さい。
.toBeTruthy()
#
値がどのようなものかを気にせず、真偽値のコンテクストの中で値が真であることを確認したい場合は.toBeTruthy
を使用して下さい。 例えば、以下のようなアプリケーションコードがあったとします:
thirstInfo
がどんなものを返すかは特に気にしないでしょう - true
もしくは複雑な値を返すかもしれませんが、それでもコードは動作します。 だからラクロワ飲料を飲んだ後にthirstInfo
が真(またはそう類推される値) を返すことをテストするには、次のように書くことができます:
JavaScriptでは、偽と類推される6つの値があります: false
、 0
、 ''
、 null
、 undefined
、 そして NaN
です。 他の全ては真と類推されます。
.toBeUndefined()
#
関数が呼ばれた際にエラーを投げることを確認するには.toThrow
を使用して下さい。 例えば、タコ味なんて気持ち悪すぎて飲めないのでdrinkFlavor('octopus')
が例外を投げることをテストしたい場合、次のように書くことができます:
expect(bestDrinkForFlavor('octopus')).toBe(undefined)
とも書くことができますが、undefined
を直接コード内で参照するのは避けたほうが実務上良いでしょう。
.toBeNaN()
#
値が NaN
であるかを検証するには、 .toBeNaN
を使用してください。
.toContain(item)
#
アイテムが配列内にあることを確認したい場合は、.toContain
を使用します。 配列内のアイテムをテストするために、 このマッチャは===
を使用して厳密な等価性のチェックを行います。 .toContain
は、ある文字列が別の文字列の部分文字列であるかをチェックすることもできます。
例えば getAllFlavors()
が風味の配列を返し、lime
がその中にある事を確認したいなら、このように書くことができます:
.toContainEqual(item)
#
特定の構造と値を持つ要素が配列に含まれていることをチェックしたい場合は.toContainEqual
を使用して下さい。 配列中のアイテムをテストするために、このマッチャはオブジェクトIDではなく、再帰的に全てのフィールドの等価性を確認します。
.toEqual(value)
#
オブジェクトインスタンスのすべてのプロパティを再帰的に等しいかの検証 (「深い」等価性としても知られています)には、 .toEqual
を使用します。 It calls Object.is
to compare primitive values, which is even better for testing than ===
strict equality operator.
例えば、 .toEqual
と .toBe
は以下のテストスイートで異なる振る舞いをするので、全てのテストがパスします:
注意:
.toEqual
は2つのエラーに deep equalityを実施しません。 エラーオブジェクトのmessage
プロパティのみを等価性の比較対象とします。 エラーに対するテストは.toThrow
マッチャの使用をお勧めします。
特にレポートが大きい場合には、プロパティ間の差分は、テストが失敗する理原因を解明することに寄与しません。 例えば、バッファに同じ内容が含まれているかどうかをアサートするには、 Buffer
クラスの equals
メソッドを使用して下さい。
- rewrite
expect(received).toEqual(expected)
asexpect(received.equals(expected)).toBe(true)
- rewrite
expect(received).not.toEqual(expected)
asexpect(received.equals(expected)).toBe(false)
.toMatch(regexp | string)
#
文字列が正規表現と一致することを確認するには.toMatch
を使用して下さい。
例えば、essayOnTheBestFlavor()
がどのようなものか正確には分からないけれども本当に長い文字列を返すこと、そして grapefruit
という文字列がその中のどこかに含まれるべきであるということを知っているとしましょう。 以下のコードでテストできます:
このマッチャは正規表現と照合する対象に文字列も取ることができます:
.toMatchObject(object)
#
JavaScript オブジェクトが、あるオブジェクトのプロパティのサブセットに一致することを確認するには.ToMatchObject
を使用して下さい。 期待されるオブジェクトに含まれないプロパティを含む引数のオブジェクトについても一致します。
オブジェクトの配列を渡すこともでき、その場合はメソッドは期待する配列の対応するオブジェクトと引数の配列の各オブジェクトが( 上述のtoMatchObject
と同じ意味で) 一致する場合のみ真を返します。 このAPIは引数の配列が余分な要素を持つことを受容する arrayContaining
とは反対に、2つの配列がその数で一致することを確認するのに便利です。
プロパティは値またはマッチャでマッチすることができます。
.toMatchSnapshot(propertyMatchers?, hint?)
#
この API は最も最近のスナップショットと一致することを確認します。 詳細については the Snapshot Testing guide を確認して下さい。
You can provide an optional propertyMatchers
object argument, which has asymmetric matchers as values of a subset of expected properties, if the received value will be an object instance. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties.
You can provide an optional hint
string argument that is appended to the test name. Although Jest always appends a number at the end of a snapshot name, short descriptive hints might be more useful than numbers to differentiate multiple snapshots in a single it
or test
block. Jest sorts snapshots by name in the corresponding .snap
file.
.toMatchInlineSnapshot(propertyMatchers?, inlineSnapshot)
#
値が最も新しいスナップショットにマッチすることを保証します。
You can provide an optional propertyMatchers
object argument, which has asymmetric matchers as values of a subset of expected properties, if the received value will be an object instance. It is like toMatchObject
with flexible criteria for a subset of properties, followed by a snapshot test as exact criteria for the rest of the properties.
Jest adds the inlineSnapshot
string argument to the matcher in the test file (instead of an external .snap
file) the first time that the test runs.
詳しい情報については、インラインスナップショットのセクションを参照してください。
.toStrictEqual(value)
#
Use .toStrictEqual
to test that objects have the same types as well as structure.
Differences from .toEqual
:
- Keys with
undefined
properties are checked. e.g.{a: undefined, b: 2}
does not match{b: 2}
when using.toStrictEqual
. - 配列が疎であるかをチェックします。 例えば
.toStrictEqual
を使用している場合には、[, 1]
は[undefined, 1]
と一致しません。 - Object types are checked to be equal. e.g. A class instance with fields
a
andb
will not equal a literal object with fieldsa
andb
.
.toThrow(error?)
#
Also under the alias: .toThrowError(error?)
関数が呼ばれた際にエラーを投げることを確認するには.toThrow
を使用して下さい。 例えば、 関数bestDrinkForFlavor(flavor)
が'octopus'
味が与えられた時にundefined
を返すことを確認したいとしましょう。 タコ味の美味しい飲み物なんてありませんから:
注意: 関数の中のコードはラップしてください。 そうしなければエラーが補足されず、アサーションは失敗します。
You can provide an optional argument to test that a specific error is thrown:
- 正規表現: エラーメッセージがパターンに マッチする か検証します
- 文字列:エラーメッセージが文字列を含む か検証します
- error オブジェクト: エラーメッセージがオブジェクトのmessageプロパティと等しいかを検証します
- errorクラス: errorオブジェクトがそのクラスのインスタンスであるかを検証します
例えば、drinkFlavor
はこのようにコーディングされたとしましょう:
いくつかの方法でこのエラーが投げられることをテストできます:
.toThrowErrorMatchingSnapshot(hint?)
#
関数が呼ばれた際に直近のスナップショットと一致するエラーを投げることを確認するには、 .toThrowErrorMatchingSnapshot
を使用して下さい。
You can provide an optional hint
string argument that is appended to the test name. Although Jest always appends a number at the end of a snapshot name, short descriptive hints might be more useful than numbers to differentiate multiple snapshots in a single it
or test
block. Jest sorts snapshots by name in the corresponding .snap
file.
例えば、 風味が'octopus'
ならば必ずエラーを投げるdrinkFlavor
関数があり、次のようなコードだったとします:
この関数のテストはこのようになります:
そして次のようなスナップショットを生成します:
スナップショットテストについての詳細はReact Tree Snapshot Testingを確認して下さい。
.toThrowErrorMatchingInlineSnapshot(inlineSnapshot)
#
Use .toThrowErrorMatchingInlineSnapshot
to test that a function throws an error matching the most recent snapshot when it is called.
Jest adds the inlineSnapshot
string argument to the matcher in the test file (instead of an external .snap
file) the first time that the test runs.
詳しい情報については、インラインスナップショットのセクションを参照してください。