Closed akabekobeko closed 3 years ago
テストが落ちたファイルと項目はわかるものの、テスト コード行が buildProcessorTestingCode
内になることがわかりにくいのでやめるか否か検討しようという issue です。
例えば #50 対応のため改行変換をオプショナルにすると、これを利用している ruby のテスト失敗は以下のようにレポートされる。
FAIL tests/inline/ruby.test.ts (5.167 s)
● ruby with newline
expect(received).toBe(expected) // Object.is equality
- Expected - 4
+ Received + 2
root[1]
- └─0 paragraph[3]
+ └─0 paragraph[1]
- ├─0 text "{a"
- ├─1 break
- └─2 text "b|c}"
+ └─0 text "{a\nb|c}"
8 | ) => (): any => {
9 | const vfm = VFM({ partial: true }).freeze();
> 10 | expect(unistInspect.noColor(vfm.parse(input))).toBe(expectedMdast.trim());
| ^
11 | expect(String(vfm.processSync(input))).toBe(expectedHtml);
12 | };
13 |
at Object.<anonymous> (tests/utils.ts:10:50)
at processTicksAndRejections (node:internal/process/task_queues:94:5)
ファイルと項目から呼び出し元をたどれるが buildProcessorTestingCode
で失敗する箇所が複数あると非直感的に思われる。もう一つの理由として #50 対応により VFM のオプション値についてもテストしたいのだが、その場合は buildProcessorTestingCode
内の VFM 生成を制御するために引数の追加が必要。
この関数をやめると定型処理こそ冗長になるが utils.ts
として文字列まわりのユーティリティ (各 expect
で指定しているもの) を提供すればよさそう。
実際に変更してみようとしたが、この関数を消すよりも引数追加するほうがよい気がしてきた。VFM に指定する StringifyMarkdownOptions
のパラメーターはすべてオプショナルなので、これを引数にしても変更は少なくて済みそう。
引数でオプション追加してみたらよさそうな感じなので issue のタイトルを変更。ちなみに実装はこんな感じ。
export const buildProcessorTestingCode = (
input: string,
expectedMdast: string,
expectedHtml: string,
options: StringifyMarkdownOptions = {
style: undefined,
partial: true,
title: undefined,
language: undefined,
replace: undefined,
},
) => (): any => {
// ...中略...
}
呼び出し元は変更したいオプションのみ指定すれば済む。
テスト用コードのみの変更でエンド ユーザーにはリリースされないため CI を通ったことをもって close する。
Since there are many standard VFM tests, the processing is standardized by
buildProcessorTestingCode
. However, if the test fails, the Jest report points to thebuildProcessorTestingCode
rather than the caller, making it difficult to investigate.Therefore, stop buildProcessorTestingCode and run the test directly.