状況
ユーザーストーリーにあるように16個のユニットテストを書いた場合、FCCのテストをパスすることが出来ました.
しかし,私はより効率的にテストを行う方法(あらかじめユニットリストを作成し、mapメソッドで順番にテストする)を考えました.
/tests/1_unit_tests.js
の199~209行目のコメントアウト部分
しかし、この方法では、ローカルテストは合格するものの、FCCのテストは合格しませんでした.
フィードバックをいただきたい点
FCCのテストに合格しなかった原因は何でしょうか?
テスト回数が16回に満たないためでしょうか?それともテストコード自体に間違いがあるのでしょうか?
また,私が考えたように、テストを1つにまとめるのは良い考えなのでしょうか?それとも推奨されないのでしょうか?(もしそうでなければ、なぜ推奨されないのでしょうか?)
参考
sidemt
2
こんばんは!投稿ありがとうございます。
freeCodeCampのサイトに提出した際のテストが失敗する理由は、「16 件のユニットテストがすべて記述され、成功する状態になっています。」というテストのみが失敗している状況であれば、テストの件数が16件に満たないためです。
また,私が考えたように、テストを1つにまとめるのは良い考えなのでしょうか?
これは、一般的にはあまり良くないとされています。
convertHandler.js
のコードをどこか変更して、わざとテストが失敗する状態を作ってから npm run test
コマンドでテストを実行してみると、違いがわかりやすいと思います。
16 件の確認点についてそれぞれテストを書いていれば、テスト結果を見てどのテストが失敗したかを確認することにより、具体的にどんな問題が起きているのか知ることができますが、
テストを1件にまとめてしまうと、どこかに何か問題があることしかわかりません。
理想的には、1件のテストケースでは1つのことだけをテストするのが良いとされています。
1 Like
返信いただきありがとうございます.
テストを1つにまとめない方が良い理由,理解することが出来ました.
新たな疑問があります.
1件のテストケースでは1つのことだけをテストするのが理想的とされているのであれば,
私が/tests/1_unit_tests.js
で行っているようなランダムな数を生成する(つまり,テストの度に入力値が変化する)テストも望ましくなく,何かしら固定値を入力すべきなのでしょうか?
sidemt
4
良い質問です! 
すみません、私の言った「1つのこと」というのは、1つの確認点という意図でした。テストの目的を1つに絞るということです。
それとは厳密には少し違う理由になるのですが、質問していただいた通り、入力値は固定する方が良いと思います。
ランダムテストという、ランダムな操作を行って不具合を見つける分野もまた別にあるのですが、このプロジェクトで書いているようなユニットテストでは、同じコードに対して同じテストを何度実行しても同じ結果が得られることが望ましいです。(ユニットテストは単体テストとも呼ばれます。)
自動化されたユニットテストは、コードに手を加えた際に意図しない変更(不具合)を発生させてしまっていないか検出する目的で繰り返し使われることが多いので、実行するたび入力値が変わってしまうと、今まで成功していたテストが急に失敗した時に、コードが悪かったのか、入力値が悪かったのか分からなくなってしまいます。
「1という値を入力すると、2という値が出力される」というような、シンプルな確認を行うテストだと考えるのが良いと思います。
1 Like
入力値を固定した方が良い理由,ユニットテストの目的と共に理解することが出来ました.
ありがとうございました!
1 Like