テストしやすいコードとシンプルな設計
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッド
キャスト番組です。
最近、スライドなしで喋ることが多かったかなと思います。自動テストの話と言いつつも、自動化ってどういうものなんだろうっていう概念的な話が多かったので、スライドなしで喋っていることが多かったかなと思って
います。
ただ、今日ちょっと話そうと思っているのはですね、コードがどういう風になればいいかっていう、そういう考えの話をすることがあるので、コードを見せながら説明できない回っていうのはやっぱり正直あるし、今回は
それに当たるかなと思っているので、今回はスライドありで喋っていきたいなと思います。
ということで、今日のテーマはですね、テストを書きやすいコードはシンプルな設計になりやすいよっていうことについて話していきたいと思います。ということで、今回も btesting.fm スタート
です。
ということで、今日はテストを書きやすいコードはシンプルな設計になりやすいという話を進めていきます。
それはどういうことかっていうのは、やっぱりちょっと例題を用いていろいろ喋っていければなぁと思っています。
階乗計算プログラムの実装例
ということで例題ですが、以下のプログラムを実装しなさいと。
1から10までのいずれかの整数を入力すると、その数値の会場の計算結果が現れると。
それ以外の整数を入力するとマイナス1と出力する。そんなプログラムがあったとします。
例として3って入力したら3の会場って3×2×1で6になるので6って出力されますよ。
3って入力したら6って出力されますよみたいな。そういうものを実装してほしいと。
1から10以外の整数、だから11とかそういうのを入力するとマイナス1と出力するみたいな。そういうものがあったとします。
このプログラムを実装しなさいっていうと、じゃあどういうふうに実装するか。
一番単純でわかりやすい話としては、これで4分で回すとか、ファイル分で回すとか、そういうのがあるかなと思っています。
何かっていうと、これ1から10以外の整数だったらマイナス1を出力するっていうのは今回ここで何かしてるんですけれども、
1から10の値を入力するっていったときに、結果、リザルトの変数に1を入れといて、
例えば4分で1からその入力値の値を入力して、それの4分を回してその分だけ掛け算していけばいいと。
最後それがプリントして出力するみたいな。こういうのが思い浮かぶかなと思います。
もちろん言語によって書き込みが違ったりとか、アルゴリズムとして4分ではなくて、ファイル分を使って表現しようとする人もいるかなと思っています。
if文による分岐実装の落とし穴
ただ一方で、今回のお題って1から10までの数字を入力したらそれに対応して会場の値を出すっていう話でいくと、
要は1だったら1を出力する、2だったら2×1で2を出力する、3だったら3×2×1で6を出力するみたいに、
この値を入力したらこの値を出力するっていうのは決まってるっていうことで言えば、こういうふうにif分で分岐して書いてもいいんですよねと。
1だったら1を出力しますよ、2を入力したら2を出力しますよ、3を入力したら6を出力しますよっていうふうに、
入力と出力が1対1で関係しているので、こういうふうにif分で分岐して書くこともできますよねと。
ただこれってよくよく今回の今のスライドの画面を見てもらえればと思うんですけど、今回のこれって一箇所ちょっとあえて間違いを書いています。
何かっていうと4の時ですね。4の時ってここでは28が出力されるって書いていますけれども、よくよく考えてみると4の時って4×3×2×1なんで24が答えになるはずですよね。
今回のここつまり28ってこれ間違ってるんですよね。
じゃあこの間違いを見つけるためにはどうすればいいかっていうと、このif分で分岐している場合は1の時1出力されて2の時2出力されて3の時6出力されて4の時24が出力されるよねっていう全部のテストを書か
ないとこれおそらく見つけられないんですよね。
一方で4分の方はこれ全部1の時2の時3の時4の時って多分やらないと思うんですよね。
テストから設計を見直す
つまりこれ何言いたいかというとですね。テストコードが書きづらい、要はたくさんのテストが必要みたいな話とか、あとはテストコードを書くにあたってちょっと複雑になっているようなコードっていうのは、これはそも
そもの実装コード自体がシンプルではないコードになっている可能性が高いと言えます。
つまりテストコードをどういうふうに書こうって考えることが、実はもともとの実装とか設計がもっとシンプルにできないかっていうフィードバックのタイミング、きっかけになるんですよね。
これが自動テストを書くと言った時に、自動テストを書くというかテストコードを書くときの良さの一つです。テストを書きやすいコードっていうのはどうなるかって考えるとシンプルな設計になりやすいという話にな
ります。
まとめとお便り案内
なので最初に開発とか実際にプロダクトのコードを実装した後に、さあ終わったテストの番だっていうふうになってしまうと、そもそもこれシンプルにできるぞっていうふうなことを後から考えることになってしまって、手
戻りがやっぱり発生してしまうんですよね。
そうならないようにやっぱりテストコードから考えるとかテストから考えるとシンプルな設計につながるっていうところがわかっていただけるかなと思います。ということで今日はテストを書きやすいコードはシンプ
ルな設計になりやすいというお話をしてきました。
はいエンディングです。 btesting.fmではリスナーさんからのお便りを募集しています。エピソードの感想や私に聞いてみたい質問やテストのお悩みなどをどんなことでも構いません。投稿フォームは番組概
要欄にあります。またエピソードの感想はハッシュタグbtesting banscotestingでxのポストをお願いいたします。
今日の話で言うとシンプルな設計につながるテストコードというかテストの話をしてきましたけれども、そう考えてみると自分もテストをやってたらこういうシンプルなことにできたなみたいなそういう体験談とかもしあれ
ばハッシュタグに投稿していただければと思います。
もしもこれからも聞きたいという方はお手持ちのポッドキャストアプリで番組のフォローもお願いします。最新回が上がった時にすぐに気づけると思います。ということで今回はここまでです。それではまた次回バイバイ。
