本記事はテストコードを「書いたことない」、「いらない」、「意義がわからない」
といった方々に、「書いたらちょっとはいいとこあるよ」と紹介する記事です。
そもそも書き方がわからない
※バリバリテスト書いてる人は飛ばしてください
テストコードの書き方って習ったことありますか？
そういえばないなーなんか難しいことやるんでしょ？
って方もそれなりの数いるような気がします。
まず結論から言えば、テストコードは基本的に、
割と泥臭いよ！
なんか自動的にソースファイル内の関数引っ張ってきてくれて、
値評価とかもしてくれる。でも難しいんでしょ？
と思ってたりする人もいるんじゃないでしょうか。
そう思っていた時期もありました。
(探せばあると思いますがたぶんお金かかる系。むしろお金取れる系)
簡単に例を挙げますと、
犬の鳴き声を国を指定して取得する関数
def dog_bark(country):
if country == 'Japan':
return u'ワンワン！'
elif country == 'USA':
return u'Bow wow！'
else:
raise NotImplementedError
のテストコードは
from dog_bark import dog_bark
def test_dog_bark():
assert u'ワンワン！' == dog_bark('Japan')
assert u'Bow wow！' == dog_bark('USA')
となります。
実際にdog_bark関数を実行して、想定した結果文字列と直接比較するというコードです。
世に言うテストコード書こうぜ！という主張はこんな感じのコードを量産しようぜ！
ということになります。特に難しいことはないですね。
テスト実行は例えばPythonのPytestなら
$ py.test test_dog_bark.py
でOKです。もしテスト関数を増やしたとしても勝手にファイル内のテストを認識して
実行してくれます。
ちなみにどの言語のどのテストフレームワークもこのくらいの機能はあります。
(コンパイルがいる言語は多少手間が増えます)
テストを書くのがめんどくさい
テストの書き方はわかったけど、「結局アプリを起動して確認すればいい」
という方、その通りです。ただ、
- そのアプリが起動できる状態になるのはいつですか？
- その機能をアプリ内で確認できる状態になるのはいつですか？
- アプリ内で確認できるようになったとして、逐一コードを直す度にアプリを
再起動して画面移動して手でパラメータ入力して目で見て確認とやるのですか？
コマンドラインで一行コマンド打ってPCが勝手にテストしてくれるのが一番楽デショー！？
そうです。実際のアプリ内で確認する方が回数をかさむとはるかに面倒なのです。
品質のためという主張も確かに正しいと思いますが、ここではあえて
品質とかいいから楽するためにテスト書こうぜ！
と主張します。テスト書くと意識が高いとかどうでもいいんですって。(暴論)
プログラマは楽するために苦労してナンボって言葉もあるし。
そもそもテスト書けば品質いいとかそのテスト自体の正しさは誰が保証してくれるのさ・・・
またそれに加えてテストが通ったところまでは完成とみなせるので、
進んでる感を得られる
というのもなかなかに重要。
仕様変更で結局捨てるはめによくなるのもお約束
設計力もつきますよ
開発中にテストを書こうとしても、
必要な関連機能が未実装とか、マスタデータがまだない
という状況ありますね。できるまで待ちますか？
うまくモジュール分割したりモックを使ったりすれば書けるのですよ
さらに、こうして書かれたテストは
他モジュールや変動するマスタデータから独立した常に動くテスト
となります。これは重要なことです。
バグフィックスや機能拡張の際の影響範囲がすぐわかるのですから。
もちろんモジュール分割等するにはそれなりの学習や経験が必要ですが、
意識するかしないかはプロダクト全体の出来に大きく関わってくると思います。
(結局意識の高さの話)
まとめは、TDDやろう！
まとめとして
- テストコードで動作確認した方が楽
- 設計もいい感じになる
というかこれら普通にTDDです。
そもそもTDDにテスト書いて品質良くしましょうな目的はないんですよね。
副次的にテストが残るからリグレッションとかに使えば品質も良くなるよね、
という後付けだったり。
ただ個人的に猫も杓子もTDDなのはどうかと思うので、とりあえず、
テストコードで楽しよう！
というまとめで。