最初の認識
テストよくわからん。とりあえず実装した機能にはかいといて、
自分がわかる範囲網羅すればいいの？
くらいの認識でいた。でも多分これじゃよくないんだろうなぁとなんとなく思ったので、一旦テストについてまとめてみることにした。
テストの書き方いろんな思想があって、
A記事ではちゃんと全部網羅せなあかんで！って書いてると思ったら、
B記事ではコストがかかるから全部は書かなくてええわいー
みたいな感じで書いてるところがあって、
記事の内容とか人から言われたことを素直に聞きすぎるChibiは
「あーなにを参考にすれば・？？？どれが正しいん？？あーーーー？？？」
ってなってました。
なので今回は自分の思想をきちんと持つためにメモ書き程度に書いていこうと思います。
テストの種類
テストの種類ってどーいうのがあるのかなと思って、会社の人に話を聞いてみたら、
「e2eとユニットテストがあるよ」と言われたので、他にもないのかと思って色々調べてみた。あとE2Eと聞いた時はてなマークが浮かんだので、それについても調べた。
この人はテストは大きく分けて２つ、E2Eとユニットテストだよ。
https://fukatsu.tech/e2e-rails
とかいているけど、開発段階での一般的なテストの種類は、「単体テスト」「結合テスト」「システムテスト」とのこと。
それぞれの説明が書いているこのサイトの記事を一部抜粋しました。
https://anken-hyouban.com/blog/2019/11/21/test-all/
単体テスト：単体テストとは作成したモジュール単位で設計書にて要求された要件・機能を満たしているかどうかを確認、検証するテスト工程です。
結合テスト：結合テストとは複数のモジュールを組み合わせてシステムが正しく連携し合い、不具合なく動作するかを確認、検証するテスト工程です。
システムテスト：システムテストとはシステムが全体をとして要求された機能や性能を満たしているかどうかを検証を行うシステム開発工程におけるテストフェーズの最終段階のテスト工程です。
うむ。なんとなく理解した。・・気がする。
じゃーE2Eってどこに当てはまるの？ってなったので、調べてみた。
こちらのサイトでは、結合テストフェーズで実行されるとのこと。
https://wagby.com/manual8/wtf.html
E2Eテスト：E2E (End to End) テストとは、システム全体が正しく動作することを確認するものです。具体的には「利用者による画面操作（Web ブラウザの操作）により、想定通りの動作となっていることを確認する」ことを指します。
話が単体テストからズレてきたので、単体テストの利点と課題を書いてみる。
単体テストの利点とデメリット
単体テストの利点と課題をホワホワ考えてみた。
利点なら１つ１つのモジュールがしっかり機能するよ。ということを証明できるところかなぁと・・だからデグレとか少なくなるなという感じ・・
ただ、想定しているものしか対応できないので、見逃しているものがあったらエラーになる・・当たり前だけど。あとは、テスト作成するのに時間かかるよなぁと・・（でもデグレが起きて直す時間・手間を考えたら、作成する時間とあまりかわらなかったりするのかな。）
みたいな感じしか頭からでてこない。
よし、いろんなサイトからデータを集めてみる。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
まずこのサイト。
https://www.geekly.co.jp/column/cat-technology/1903_058/
メリット : ひとつのモジュールに特化して徹底したテストができる
デメリット: コストがかかる
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
次にこのサイト
https://engineer-club.jp/what-is-unit-test#i-3
メリット：
1 プログラム完成直後の一番「どう動くべきか」が明確に記憶に残っているホットな時期に検証できる点
2 テスト対象を他のプログラムから切り離して徹底的に検証できるところが利点
デメリット：
テスト対象を動作させるための『付加コード』を作成する必要がある場合や、付加コードを含めた“テスト環境”を管理する「作業負荷」が大きくなってしまう
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
次にこのサイト
https://www.techmatrix.co.jp/t/quality/unittest.html#:~:text=%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%88%A9%E7%82%B9,%E3%82%92%E4%B8%8B%E3%81%92%E3%82%8B%E5%8A%B9%E6%9E%9C%E3%81%8C%E9%AB%98%E3%81%84%E3%80%82
メリット：
1: モジュールが結合される前の段階でテストが実施されるため、問題の原因の特定や修正が容易
2: 妥当性の高いテストケースを資産として残すことができ、後の拡張開発や改修時にも再利用できる。
デメリット：
1: 開発者にかかるテストの負担が大きくなりやすい。
2: テスト実施にある程度のスキルが必要なため、導入が難しい場合がある。
3: スケジュールの関係で単体テストに時間を割くことができない場合など、テストが省略されたり不完全になりやすい
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
なるほど。自分なりにメリットデメリットをまとめてみる。
メリット：
1: 1つのモジュールに特化したテストができる。結合する前にテストを実施するので、問題の特定が容易にできる。
2: テスト対象を他のプログラムから切り離して検証できるので、問題特定に時間を使わなくてよくなる。
3: テストケースをたくさん残せる。
デメリット：
1: テストの負担が大きくなる。
2: スキルがいるので、導入が難しい。
3: 繁忙期はテスト書く暇がないからテストがあるやつとないやつが存在しちゃう。
デメリットの方はなにかとコストがかかるからみたいな感じで書いてるところが多くて、それ故にコストを削減するために単体テストは軽視されがちなのかな？と思った。わからんけど。
でも最初に書いたデグレが起きて修正をしたり、その修正のために調査したりする時間が増えていったらコスト増えるし、テスト書いてた方が安心できるからいいのでは？
とやっぱり思ったので、単体テストは軽視したらいけないなぁとなんとなく思った。
なんとなく単体テストちゃんとしないといけないなぁと思ったので、次に単体テストの種類について調べていく。
単体テストの種類
単体テストは
ホワイトボックステストとブラックボックステストっていうのがあるらしい。
名前は聞いたことあるけど、これって単体テストの種類だったんだっけ・・
授業で習ったよなぁ・・先生すまんの・・と思ったので、ちゃんと調べていく。
https://www.techmatrix.co.jp/t/quality/unittest.html
このサイトが優秀すぎるので、記事をまた抜粋させていただきまする。
一言でホワイトボックステストとブラックボックステストを言うと、
ホワイトボックステスト：テスト対象関数またはメソッドの内部構造に着目
ブラックボックステスト：テスト対象関数またはメソッドの外から見た機能（入出力）に着目
らしい。うちの会社はホワイトボックステストをやってるのかな？
ブラックボックステストはあまり力入れてる感じがしない。
これだけだとまだよくわからないので、
もう少し細かくブラックボックステストとホワイトボックステストについて調べてみる。
https://hnavi.co.jp/knowledge/blog/white-box-test/
こちらのサイトにかいてるのがわかりやすかった。
ホワイトボックステストは、すべてのプログラムが意図したとおりに動作しているかを確認するためのテストで、ロジックとか制御の流れが正常かどうかを検証するために、
「作り手側のテスト」と言われるらしい。
網羅的なテストであるため、条件分岐を基準としたテストや例外処理を重視したテストなどの動作確認ができる。
詳細設計書を基に作成するので、間違ってたら対応はできない。
めちゃわかりやすい。
次にブラックボックステスト。
ブラックボックステストは、システム自体の仕様を満たしているかどうかを確認する機能のテストです。画面表示などユーザーインタフェースの不具合やレイアウト崩れなど、正しい出力ができているかを確認するため、「ユーザー側のテスト」といわれています。
情報の処理前と処理後の値の変化や、画面の状態といったインプット・アウトプットの結果のみを確認することで検証を行います。
理解・・・とてもわかりやすい・・・
この記事では最終的にブラックボックステストとホワイトボックステストは織り交ぜていい感じにやっていこう。みたいな感じでかいてある。
じゃー実際にどうやって実施していくのかを調べてみる。
ホワイトボックステスト・ブラックボックステストの実施方法
ホワイトボックステストは、内部構造の条件を網羅するための網羅基準として、
「命令網羅」「分岐網羅」「条件網羅」「複数条件網羅」がある。
なんかよくいうあれだ。
命令網羅はC0、分岐網羅はC1、条件網羅はC2、複数条件網羅はMCC。
なんか一回は聞いたことあるはず。
各網羅基準をまとめる。
https://medium-company.com/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9-%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9-%E9%81%95%E3%81%84/#i-5
https://wa3.i-3-i.info/diff325test.html
命令網羅
命令網羅とは、全ての命令を最低一回は通すということ。
なのでif文があったら、１通路だけ通せばいい。みたいなかんじ。
分岐網羅とは、
「処理が枝分かれしたときの行き先を全部1回は確認するぜ！」になるようにテストを設定すること。
条件網羅とは、
「条件によって分岐する処理が出てきたとき、それぞれの条件のYes/Noを全部1回は確認するぜ！」になるようにテストを設定すること
複数条件網羅とは、
想定される条件の組み合わせをすべて網羅するということ。
分岐網羅と条件網羅の違いがいまいち良くわかってない・
でもなんとなく、本当は全部複数条件網羅ってのをしないとバグが発生するんだろうなぁとは思ったけど、かなり大変だし、見落としも有りそうだなぁと思った。
https://qiita.com/bremen/items/8b6542467d2a0066e5af
これをみたらなんとなく、全部網羅は難しそうだなぁとは思った。目指すべきなのだろうけど・・
ほかの会社はどこまでやっているのだろうか・・
よく聞くのはC0のカバレッジがどうたらとか言うけど、
基本的にはC0、C1、できればC2という感じなのだろうか。
カバレッジについて色々書いてる。からあとでもう少しちゃんとみる。
次に、今会社で使ってるテストのカバレッジを求めるライブラリについて
調べる。
SimpleCovを使っているのだが、C0までしか対応していない。
みたいな感じでかいている記事を見つけた。
あってるか調べてないからわからないけど、
その場合、SimpleCovで表示されてる値が１００％になったからって
安心はできないんだなと思った。
みんなどうしてるんだ・・・・
https://www.techscore.com/blog/2012/12/25/rails%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E7%B4%B9%E4%BB%8B-%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E3%82%AB%E3%83%90%E3%83%AC%E3%83%83%E3%82%B8%E3%82%92%E6%B1%82%E3%82%81%E3%82%8B%E3%80%8Csimp/
とりあえずまとめ
色々書いたけど、単体テストの書き方はこれがベスト！！！！！
っていうのがあんまりなかった。正解はないんだろうなぁという感じ・・
でも単体テストを軽んじることはあまり良くないと思ったし、
自分のプロダクトにもっとテストは取り入れていきたいと思った。少し認識が変わっただけでも良しっ！
このブログは完全に私の頭の中をずらずら書いてるだけなので、否定的な発言などありましたら心の中に留めておいてください。
まだ未完成なので、気付いたり気が向いたら書いていきます。
コメント