fixtures/blocks

すべての投稿コンテンツのテストのフィクスチャ

はじめに

このディレクトリには、構文解析とシリアル化のロジックをテストするためのフィクスチャファイルのセットが含まれています。

各テストは4つのフィクスチャファイルから構成されています:

fixture-name.html: 元の投稿コンテンツ。
fixture-name.parsed.json: このコンテンツに対する PEG パーサーの 期待される 出力（JS と PHP の両方のバージョンのパーサーでの 実際の 出力に対してチェックされる)。
fixture-name.json: 投稿コンテンツ内のブロックの 期待される 表現と、その属性およびネストされたコンテンツ。このファイルのコンテンツは、 実際の ブロックオブジェクトと比較されます。
fixture-name.serialized.html: 解析されたブロックオブジェクトに対して serialize を呼び出したときの 期待される 結果。このファイルの内容は、 実際の 再シリアライズされた投稿の内容と比較されます。この最後のステップでは、記事を開いて保存し直すことをシミュレートします。

すべてのブロックは、そのブロックの解析とシリアライズをテストするために、少なくとも一つのフィクスチャファイルのセットを持つ必要があります。さらに、ブロックの各非推奨プロセス（deprecation）もフィクスチャを持つ必要があります。

これらのフィクスチャは以下のような名前にしなければなりません。core__blockname{__*,}.{html,json,serialized.html} たとえば、core/imageブロックでは、以下の4つのフィクスチャファイルが存在しなければなりません:

core__image.html (or core__image__specific-test-name.html). Must contain a  block.
core__image.parsed.json (or core__image__specific-test-name.parsed.json).
core__image.json (or core__image__specific-test-name.json).
core__image.serialized.html (or core__image__specific-test-name.serialized.html).

理想的には、ブロックのすべての重要な属性や機能がこの方法でテストされるべきです。テストケースの追加という形での新たな貢献をいつでも歓迎します。これは、バグを特定し、将来の再発を防ぐための素晴らしい方法です。

新しいフィクスチャを追加する時は上記の最初のファイル（ 1, 例core__image.html）のみを手動で作成する必要があり、他のファイルはこの最初のファイルから生成されます。

最初のファイルを作成するには：

次に、2から4のファイルを生成するために、次のコマンドをプロジェクトのルートで走らせます:

npm run fixtures:regenerate test/integration/full-content/full-content.test.js

このコマンドを使用する際には、必ず手動で .json と .serialized.html ファイルの内容が期待通りであることを確認してください。

特に、isValid プロパティが true であることと、属性が正しくシリアル化されていることを確認してください。

既存のテストのためのフィクスチャの更新プロセスは作成手順と似ています:

ファイルを再生成するコマンドを実行します:

npm run fixtures:regenerate test/integration/full-content/full-content.test.js

フィクスチャを再生成した後、(git または github を使用して) 差分を確認してください。期待する変更になっているか、ブロックが有効か (isValid が true か) を確認します。