とりあえず抑えておきたい Railsでの「テストの内容」の考えかた #kaigionrails /Test code concepts to keep in mind for now with Rails

とりあえず抑えておきたい Railsでの「テストの内容」の考えかた Kaigi on Rails 2022 2022/10/22 しんくう@shinkufencer

本日しゃべること 2 今回はテストのなかでもテストコードに関して大きく2つに分けてお話します 1. テストコードを書くと何が嬉しいのか？ 2. 嬉しいポイントを踏まえた上でどういうことを書くといいの？

今回のまえおき • コードでいくつか具体例を紹介しますが、そちらはRSpecで記述したものをご紹介します • いくつかのコードは見ずらい部分もあるので、公開しているスライドをご参照いただければ幸いです 3

テストコードは書くと何が嬉しいのか？ 4

そもそもテストコードとは • 今回は「”開発対象のプログラムコード”に対するテストをプログラムコードで書いたもの」をテストコードと呼びます • テストコードによってテストの実施を自動で行っていく取り組みのことを『自動テスト』と表現します • このテストコードを用いる自動テストの性質をとらえると嬉しいポイントが考えやすい
5

6 (テストという大きな枠組みの中で自動テストがどういうものかという話において) 自動テストって名前で開発者がやっているものって自分たちが考えた通りにソフトウェアは今もこの瞬間も動いているかどうかを確かめるという行為である – @t_wada texta.fm「9.
The 20th Anniversary of TDD 」の和田卓人さんの発言より https://texta.pixta.jp/entry/2022/03/10/150000

自動テストを用いたテストコードの性質 7 • 「自分たちが考えたとおり」つまり『自分たちが定義した仕様のとおり』 • 「今もこの瞬間も動いているかどうか」つまり『実装した直後も新しく違う機能を追加した直後も動いているかどうか』 • 未知の不具合を見つけ出すのではなく、既知の部分が問題ないかを『確かめる(checking)』
『仕様の通りに動いているかどうかをいつでも確かめることができる』のがテストコードを用いた自動テストの性質

テストコードを用いた自動テストはどの場面で活きる？ 8 この自動テストの「確かめることができる」性質を考えたときに様々なメリットはあるが、わかりやすいメリットを2つ紹介します。 1. プログラムの動作確認が実装直後に可能 2. 変更を加えた際に変更箇所以外が壊れていない確認（回帰テスト）がいつでもできる

嬉しいポイント① 実装直後の動作確認 9

実装直後の動作確認 • 例えば「ユーザーの名前を編集する画面」があったときに以下の仕様を実装する場合、テストコードを書かない場合と書いた場合で比較して考えてみます 10 ▼仕様 User.nameのバリデーション名前が5文字以下はエラー。・「めでぃかる太郎」はOK
・「のーと次郎」はエラー

リリース手動動作確認 Viewの修正実装直後の動作確認 11 Controllerの修正 Modelの修正仕様に沿って Userモデルのnameに Validationを入れよう
開発実装担当テストコードを書かない場合… validates :name, length: { minimum: 5 } ▼仕様 User.nameのバリデーション名前が5文字以下はエラー。・「めでぃかる太郎」はOK ・「のーと次郎」はエラー

リリース手動動作確認 Viewの修正実装直後の動作確認 12 Controllerの修正 Modelの修正エラーのときには編集ページにとどまるように edit
actionを修正しよう開発実装担当テストコードを書かない場合…

リリース手動動作確認 Viewの修正実装直後の動作確認 13 Controllerの修正 Modelの修正エラーのときにはというエラー文言が出るようにしよう開発実装
担当テストコードを書かない場合…

リリース手動動作確認 Viewの修正実装直後の動作確認 14 Controllerの修正 Modelの修正開発実装担当あれ？5文字で入れたけど
エラーが何も出ない？確か仕様では5文字以下でエラーしたよね？手動テスト担当 ! テストコードを書かない場合… あれ？なんでだろう？もしかしてControllerに正しく値が渡ってきてない？

リリース手動動作確認 Viewの修正実装直後の動作確認 15 Controllerの修正 Modelの修正開発実装担当手動テスト
担当 ! 初手の実装誤りを一通り作った後に気づき手戻りが発生！テストコードを書かない場合… しまった！ Validateのminimumが5だと 5文字のときはsaveできる！「:minimum: 属性はこの値より小さな値を取れません。」なので指定した値自体はvalidationのerrorにならない https://railsguides.jp/active_record_validations.html#length

リリース手動動作確認 Viewの修正実装直後の動作確認 16 Controllerの修正 Modelの修正実装タイミングでテストコードを書くと… 仕様に沿って Userモデルのnameに
Validationを入れよう開発実装担当 validates :name, length: { minimum: 5 } ▼仕様 User.nameのバリデーション名前が5文字以下はエラー。・「めでぃかる太郎」はOK ・「のーと次郎」はエラー

リリース手動動作確認 Viewの修正実装直後の動作確認 17 Controllerの修正 Modelの修正実装タイミングでテストコードを書くと… 仕様に沿ってテストコードを書こう開発実装
担当 ▼仕様 User.nameのバリデーション名前が5文字以下はエラー。・「めでぃかる太郎」はOK ・「のーと次郎」はエラー仕様の記述にならって『nameが「めでぃかる太郎」だと保存できる』『nameが「のーと次郎」だと保存に失敗する』というテストコードにしよう

リリース手動動作確認 Viewの修正実装直後の動作確認 18 Controllerの修正 Modelの修正実装もテストコードも完成！テストコードを実行しよう開発実装
担当自動テスト実装タイミングでテストコードを書くと…

リリース手動動作確認 Viewの修正実装直後の動作確認 19 Controllerの修正 Modelの修正開発実装担当自動テスト
? 実装タイミングでテストコードを書くと… あれ、テストコード間違えちゃったかな…？『nameが「のーと次郎」だと保存に失敗する』というテストコードが失敗しました

リリース手動動作確認 Viewの修正実装直後の動作確認 20 Controllerの修正 Modelの修正開発実装担当自動テスト
! あれ、テストケース間違えちゃったかな…？実装タイミングでテストコードを書くと… しまった！Validateのminimumは『この値より小さな値を取れません』だから 5を指定したら5文字のときはsaveできる！早いタイミングで気付ける！『nameが「のーと次郎」だと保存に失敗する』というテストコードが失敗しました

実装直後の動作確認 • 今回のケースだとModelで発生した不具合を早期発見できることによって問題箇所に早く気付け、他の実装前に気づくことができた • テストコードを書く・実行するという作業を通して軽微なミスを発見できるので開発にあたるチーム全体としても効率を上げることができる 21

嬉しいポイント② 素早く回帰テストができる 22

素早く回帰(リグレッション)テストができる 23 ▼仕様 User.proﬁle_textのバリデーション・20文字以下はエラー・数字だけで構成されるとエラー・最初の文字に数字を使うとエラー・最後の文字に数字を使うとエラー・「バカ」が含まれるとエラー・空白文字だけだとエラー
例) 既にあるユーザのプロフィール文章のバリデーションに　『「nil」という文字列が含まれるとエラー』を追加する手動テスト担当新しいバリデーションが追加されたのか… ここって誰かが前にもテストした気がしたけど、同じことできるかな… 手動だと過去と同じ動きをすることができるとは限らない作業量がふえるとヒューマンエラーで取りこぼす可能性もある量が多いからテストの抜けもれがないようにしないと…

素早く回帰(リグレッション)テストができる 24 ▼仕様 User.proﬁle_textのバリデーション・20文字以下はエラー・数字だけで構成されるとエラー・最初の文字に数字を使うとエラー・最後の文字に数字を使うとエラー・「バカ」が含まれるとエラー・空白文字だけだとエラー
例) 既にあるユーザのプロフィール文章のバリデーションに　『「nil」という文字列が含まれるとエラー』を追加する決められたことをテストコードを通してチェックするだけならいつでもできます自動テストであれば物量が増えても素早く確認ができる機械にチェックをお願いするので抜け漏れがないコードで書かれているので抜け漏れをすることはありません自動テスト

素早く回帰(リグレッション)テストができる • テストコードは「その時点では正しく動いていた」や「変更したところで壊れたということに気づく」ということが得意 • 手動でも同様のことは可能ではあるが、テストコードのほうが手動よりも短い時間で、漏れなく実施をすることができる 25

テストコードがあると何が嬉しいのか？ 26 • 様々なメリットのうちの2つのメリットを紹介しましたがどちらにも共通して言えることは「仕様に沿っていない不具合を早期発見できる」というところ • 一般的に不具合の発見は遅れれば遅れるほど、修正の範囲が大きくなり労力がかかる傾向にあるので早く発見できればできるほど不要なコストがかからずすむ
『仕様の通りに動いているかどうかをいつでも確かめることができる』ので不具合に早く気付け、修正コストを最小限にすることに貢献できるのが嬉しいポイント

何が嬉しいのか？はわかった、が… 27 • テストコードを書く嬉しさは「仕様通り」ということを確かめることができること • しかしテストコードを書くのも開発者自身になるそのため、よりよく「仕様通り」を確かめるテストコードを書くのが大事

どういうテストコードを書くと仕様通りに動くことを確かめることができるのか？ 28

「仕様通り動く」のテストケースはどう考えるといいか • 「仕様通り動く」ことのテストコードを書いていくと、愚直に考えるべきテストのケース数が膨大になることがある • そのため「効率的」かつ「抜け漏れが少ない」テストケースを考えて、それらを実施していくことが肝心 • そのテストケースを考えていく先人の知恵が「テスト技法」 29
テストケースを作成するためのノウハウ「テスト技法」を活用することで効果的なテストコードが作成できます今回は基本的かつ使いやすい2種類を紹介します

テスト技法を考える上でのお題 30 お題：年齢を扱うクラスに文字列を生成するメソッド「output_view_text」を作成したい。生成する文字列は以下の通り • 0歳から18歳までは「幼年」 • 19歳から30歳までは「青年」 •
31歳から130歳までは「壮・老年」なお、0から130以外のものはエラーとしたい。なお、メソッドに整数値以外のものが入らないことは事前にチェックされているものとする。

ベースとなるクラス ::Plain::Age 31 module Plain class Age def initialize(age_value:) raise
ArgumentError, "値が整数ではありません " unless age_value.is_a? Integer @age = age_value end def output_view_text raise StandardError, "値が範囲外です" if @age < 0 return "幼年" if @age <= 18 return "青年" if @age <= 30 return "壮・老年" if @age < 130 raise StandardError, "値が範囲外です" end end end

テスト技法① 同値分割法 32

同値分割法 - お題をとおして使い方を考える 33 年齢ごとに考えると、人間は0歳から始まる生き物だし 0、1、2、3、4、5、6、７、8、9、10…128、129、130であとは0ではないときの-1、130を上回る値の131を試してみて 131+2=133パターンの入力値のテストを考えればいいのかな…？お題：年齢を扱うクラスに文字列を生成するメソッド「output_view_text」を作成したい。
生成する文字列は以下の通り • 0歳から18歳までは「幼年」 • 19歳から30歳までは「青年」 • 31歳から130歳までは「壮・老年」なお、0から130以外のものはエラーとしたい。なお、メソッドに整数値以外のものが入らないことは事前にチェックされているものとする。

愚直にcontextを書いていく場合 34 context "0歳の場合" do let(:age) { ::Plain::Age.new(age_value: 0) }
it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "1歳の場合" do let(:age) { ::Plain::Age.new(age_value: 1) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "2歳の場合" do let(:age) { ::Plain::Age.new(age_value: 2) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "3歳の場合" do let(:age) { ::Plain::Age.new(age_value: 3) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "4歳の場合" do let(:age) { ::Plain::Age.new(age_value: 4) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "5歳の場合" do let(:age) { ::Plain::Age.new(age_value: 5) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "6歳の場合" do let(:age) { ::Plain::Age.new(age_value: 6) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "7歳の場合" do let(:age) { ::Plain::Age.new(age_value: 7) } it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end End ## 後略 ### 愚直にやると0から130,-1と131を引数に設定した contextを133個書く必要がある

同値分割法 - お題をとおして使い方を考える 35 • 133個のテストケースの時点で書く量がかなり多い • コピペを繰り返せば作れることは作れるが書き換えミスが起きたりメンテナンスしづらいこのときに有効なテスト手法が「同値分割法」

同値分割法を利用したテストケース作成 36 1. 提示された仕様から値を意味のあるグループ（同値パーティション）に分ける。仕様として有効な値のグループを「有効同値パーティション」、無効な値のグループを「無効同値パーティション」という 2. それぞれの同値パーティションに該当する値から少なくとも1つの値を代表値として取り、その値を使ったテストケースを作成する同値分割法の考え方は以下の通り

同値分割法を利用したテストケース作成 37 • 今回のケースでは有効同値パーティションと無効同値パーティションは以下の5つとなる 0 -1 131 130 19
18 31 30 有効同値パーティション① 「幼年」有効同値パーティション② 「青年」有効同値パーティション③ 「壮・老年」無効同値パーティション① 下限以下エラー無効同値パーティション② 上限以上エラー

同値分割法を利用したテストケース作成 38 • パーティションを表に書き出して、代表値を書き足す。パーティション名有効/無効値の範囲出力される結果代表値幼年
有効 0以上18以下幼年 5 青年有効 19以上30以下青年 27 壮・老年有効 31以上130以下壮・老年 50 下限以下エラー無効 -1以下なし（エラー） -3 上限以上エラー無効 131以上なし（エラー） 200

39 context "幼年パターン、 5歳の場合" do let(:age) { ::Plain::Age.new(age_value: 5) }
it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "青年パターン、 27歳の場合" do let(:age) { ::Plain::Age.new(age_value: 27) } it "青年と出力されること " do expect(age.output_view_text).to eq("青年") end end context "壮・老年パターン、 50歳の場合" do let(:age) { ::Plain::Age.new(age_value: 50) } it "壮・老年と出力されること " do expect(age.output_view_text).to eq("壮・老年") end End context "-3歳の場合" do let(:age) { ::Plain::Age.new(age_value: -3) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end context "200歳の場合" do let(:age) { ::Plain::Age.new(age_value: 200) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end 同値分割法をベースにしたテストケース各パーティションから任意の値を拾い上げて選択しているこの場合は「5」「27」「50」「-3」「200」となる

同値分割法を利用したテストケース作成 40 • 5つのパーティションに該当する範囲をすべてやるのではなく、どれか任意の一つの値を試すことでその範囲の確認とするのが同値分割法 • そのため、今回は5つのテストケースに対応することでもともとやろうとしていた133ケース以上のケースを5つのケースで要点を確認できる • 本質的にテストしたいのは「決められた範囲内のパターンごとにちゃんと
処理が意図通り行われるか」というところであり、すべての可能性を網羅したいわけではないので、同値分割法はその点に着目したもの

同値分割法だと見つけにくいもの 41 • 同値分割法で対応するべきものを減らしたが、この5つのケースだと実は検知できていない潜在的なエラーがある。先程のコードを改めて見てみる。

おわかりいただけるだろうか… 42 module Plain class Age def initialize(age_value:) raise ArgumentError,
"値が整数ではありません " unless age_value.is_a? Integer @age = age_value end def output_view_text raise StandardError, "値が範囲外です" if @age < 0 return "幼年" if @age <= 18 return "青年" if @age <= 30 return "壮・老年" if @age < 130 raise StandardError, "値が範囲外です" end end end

仕様とそぐわない部分 43 module Plain class Age def initialize(age_value:) raise ArgumentError,
"値が整数ではありません " unless age_value.is_a? Integer @age = age_value end def output_view_text raise StandardError, "値が範囲外です" if @age < 0 return "幼年" if @age <= 18 return "青年" if @age <= 30 return "壮・老年" if @age < 130 raise StandardError, "値が範囲外です" end end end この書き方だと「年齢が130」だと文字列を返さず StandardErrorを返却してしまう仕様の意図に合わない！ ※ただしくは @age <= 130にしなければならない

44 context "幼年パターン、 5歳の場合" do let(:age) { ::Plain::Age.new(age_value: 5) }
it "幼年と出力されること " do expect(age.output_view_text).to eq("幼年") end end context "青年パターン、 27歳の場合" do let(:age) { ::Plain::Age.new(age_value: 27) } it "青年と出力されること " do expect(age.output_view_text).to eq("青年") end end context "壮・老年パターン、 50歳の場合" do let(:age) { ::Plain::Age.new(age_value: 50) } it "壮・老年と出力されること " do expect(age.output_view_text).to eq("壮・老年") end End context "-3歳の場合" do let(:age) { ::Plain::Age.new(age_value: -3) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end context "200歳の場合" do let(:age) { ::Plain::Age.new(age_value: 200) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end テストケースも見返すこのテストコードでは壮・老年パターンのテストケースは 50で設定しているため気づくことができない

同値分割法だけだと見落とされる部分 45 • プログラムの多くは「分岐」の重ね合わせであり、その分岐の周りのヒューマンエラーや認識漏れでバグが生まれるケースが多い • これを防ぐためにすべての考えうるケースをやってしまうと同値分割法を取り入れる前の状態にもどってしまう • そのため同値分割法を拡張して、分岐に関してのケースをカバーし拡張す
る手法が「境界値分析」

テスト技法② 境界値分析 46

同値分割法+境界値分析を利用したテストケース作成 47 1. 同値分割法同様にパーティションを作り、各パーティションから「代表値」をテストの値として取り上げる 2. 各パーティションの取りうる値の境界を「境界値」とし、テストの値として取り上げる 3. 1と２で取り上げた値をもとにテストケースを作成する
• 境界値分析は同値分割したパーティションの値に着目し、順序付け可能な数値の場合の境界を加える考え方は以下の通り

同値分割法+境界値分析を利用したテストケース作成 48 パーティション名有効/無効値の範囲出力される結果代表値境界値幼年有効
0以上18以下幼年 5 0,18 青年有効 19以上30以下青年 27 19,30 壮・老年有効 31以上130以下壮・老年 50 31,130 下限以下エラー無効 -1以下なし（エラー） -3 -1 上限以上エラー無効 131以上なし（エラー） 200 131

同値分割法+境界値分析を利用したテストケース作成 49 パーティション名有効/無効値の範囲出力される結果代表値境界値幼年有効
0以上18以下幼年 5 0,18 青年有効 19以上30以下青年 27 19,30 壮・老年有効 31以上130以下壮・老年 50 31,130 下限以下エラー無効 -1以下なし（エラー） -3 -1 上限以上エラー無効 130以上なし（エラー） 200 131 代表値はケースに合わせてパーティション内の任意の値をとり境界値はパーティションの範囲の上限と下限を鑑みて設定無効パーティションの場合は上限や下限が両方あるとは限らないので内容に応じて追加する

50 context "青年パターン、 30歳の場合" do let(:age) { ::Plain::Age.new(age_value: 30) }
it "幼年と出力されること " do expect(age.output_view_text).to eq("青年") end end context "壮・老年パターン、 31歳の場合" do let(:age) { ::Plain::Age.new(age_value: 31) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "壮・老年パターン、 50歳の場合" do let(:age) { ::Plain::Age.new(age_value: 50) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "壮・老年パターン、 130歳の場合" do let(:age) { ::Plain::Age.new(age_value: 130) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "131歳の場合" do let(:age) { ::Plain::Age.new(age_value: 131) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end context "200歳の場合" do let(:age) { ::Plain::Age.new(age_value: 200) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end 境界値分析を用いたテストケース（抜粋）

51 context "青年パターン、 30歳の場合" do let(:age) { ::Plain::Age.new(age_value: 30) }
it "幼年と出力されること " do expect(age.output_view_text).to eq("青年") end end context "壮・老年パターン、 31歳の場合" do let(:age) { ::Plain::Age.new(age_value: 31) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "壮・老年パターン、 50歳の場合" do let(:age) { ::Plain::Age.new(age_value: 50) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "壮・老年パターン、 130歳の場合" do let(:age) { ::Plain::Age.new(age_value: 130) } it "壮・老年　と出力されること " do expect(age.output_view_text).to eq("壮・老年") end end context "131歳の場合" do let(:age) { ::Plain::Age.new(age_value: 131) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end context "200歳の場合" do let(:age) { ::Plain::Age.new(age_value: 200) } it "エラーになること " do expect { age.output_view_text }.to raise_error(StandardError) end end 境界値分析を用いたテストケース（抜粋）このテストコードでは130と131の 2パターンテストしており、テストが失敗するので if文の記述ミスに気づくことができる

同値分割法+境界値分析を利用したテストケース作成 52 • 全件をテストせずに、一番分岐のメインの部分になる「境界」をケースに加えることでバグに気づきやすい。 • 多くのメソッドのテストは入力値に対する結果を測るものなので幅広く応用することができるこれでたくさんのテストケースをこなさなくても、少ないケース数でちゃんと動くかのチェックはできそうだ！
これで大量のテストケースをかかなくてすむ！

まとめ 53 • テストコードを含めた自動テストは『仕様の通りに動いているかどうかをいつでも確かめることができる』という性質がある • 自動テストは不具合に早く気付け、修正コストを最小限にすることに貢献できるのが嬉しいポイント • テストコードを書く際には仕様通りかをチェックできるものを作るの
が大事 • 仕様を確認するテストコードを書くときにはテストケースをつくるときのテスト技法を使うと効率よくケースをつくることができる • 同値分割法と境界値分析は使いやすい方法なので日頃から頭に入れておくと便利

54 しんくう / shinkufencer 　 @shinkufencer コード日進月歩 https://shinkufencer.hateblo.jp/ ASTERセミナー標準テキスト｜Kouichi Akiyama｜note
https://note.com/akiyama924/m/m6981810393cd Software Design 2022年3月号｜技術評論社 https://gihyo.jp/magazine/SD/archive/2022/202203 ソフトウェアテスト技法練習帳～知識を経験に変える40問～ https://gihyo.jp/book/2020/978-4-297-11061-1 Thanks! 参考にしたサイト/書籍など:

とりあえず抑えておきたい Railsでの「テストの内容」の考えかた #kaigionrails /Test code concepts to keep in mind for now with Rails

とりあえず抑えておきたい Railsでの「テストの内容」の考えかた #kaigionrails /Test code concepts to keep in mind for now with Rails

More Decks by ShinkuFencer

Other Decks in Technology

Featured

Transcript