Step15. テストコード
今日はジン先輩とフリートさんと3人で、モブプログラミングをやっていく。
騒がしいのが迷惑になるかも知れないのと、気分を変えるために会議室を借りた。
ムウさんは、学習中だ。10分迷ったら、割り込んでいいから質問に来るよう伝えてある。
「ジン先輩、フリートさん、お尋ねしたいのですが、作ったプログラムのテストって、どうしてます？」
「そりゃ自分で動かしてみて、確認しとるぞ」
「私も動かして、見ています」
「異常系はどうしてます？」
「……見たり、見なかったりじゃの。重要そうな部分だけ見とる」
「なっ……！？ それだから、貴方の所は、変なバグ出すのではないですか！私は、しっかりと境界外の値まで確認しています」
「確認しとるのはええかも知れんが、時間が掛かってしゃーないぞ。お前さんは作るのが遅いじゃろう！」
「はいはい、喧嘩しないでくださいね」
パンパンッと手を2回叩いて、2人を静かにさせる。
「運用が決まってないのであれば、どちらが悪いとかはありませんよ。では、しっかりしてなくても、してても。その確認した内容のエビデンスはありますか？」
「……ないぞ」
「私はあります。バグなく正常に動作しているのが、何よりの証拠です！」
残念だけど、客観的に判断できるものでなければ、証拠にはならないよ……言わないけど。
「では、もう１つお尋ねさせてください。今あるコードのリファクタリングを行った時に、影響がないと思われていた部分で、バグが発生した経験はありませんか？」
「あるぞ」
「あります」
「その時、他にも類似の問題がないか不安になって調べたり、再テストをするのは、時間が掛かりませんか？特にしっかり確認されている、フリートさんは負担が大きくありませんか？」
「……大変だぞ。だから、問題が発生した箇所しかみておらん」
「……きちんと全体を見直しています。と言いたいところですが、影響範囲が広い場合は、リファクタリングを諦めて、元に戻してしまうことがあります」
「ありがとうございます。お2人の対応はそれぞれ、メリット・デメリットがあって、どちらが良いとも、悪いとも、言えないですよね。今回は、それらの問題を解決する方法を提案したいと思います」
「そんな事が、出来るのか？ ……サワタリじゃからのう。もう驚かんわい」
「まさか、可能なのですか？ ……サワタリさんだから、驚くのはよしましょう」
うっ、何やら奇人変人扱いされた気がする。
「何をするかと言えば、簡単です。テストを行うプログラムを作りましょう！」
「ほぅ、それは面白い発想じゃな」
「全くです。実に興味深い方法です」
食いついてくれて良かった。
「はじめますね。まずはテスト用のモジュールを準備しましたので、こちらを使って行きます」
ソースコードを魔導投影機に映し出す。
using System;
using Tests;
namespace MagicSoft
{
public class Sample
{
// 足し算を行うメソッド
public int Add(int a, int b)
{
return a+b;
}
}
public class SampleTest : Sample // クラスの継承
{
// 足し算のテスト
public void AddTest()
{
// 1 + 2 = 3になるかチェック
Test.Assert( Add, 1, 2, 3, "=" );
}
}
}
「こんな感じで書きます。テストをするクラスを継承して、AddTestというテスト用のコードを書きます。今回は1+2が3になるかチェックしています。正解なので問題はありません。試しに実行してみますね」
[----------] 1 tests from SampleTest
[ RUN ] AddTest Assert( Add, 1, 2, 3, "=" )
[ OK ] AddTest
[ PASSED ] 1 tests.
「こんな感じでOKと表示されます」
「「おぉぉぉ……」」
「では、フリートさん、試しにAddの中身を間違えて貰ってもいいですか？」
「分かりました。やってみます」
カタカタ……タン
// 足し算を行うメソッド
public int Add(int a, int b)
{
return a-b;
}
「できました！ 足し算を行うべきところを、引き算に変更してみました」
「はい、ありがとうございます。それでは実行してみてください」
[----------] 1 tests from SampleTest
[ RUN ] AddTest Assert( Add, 1, 2, 3, "=" )
[ FAILED ] AddTest compare -1 = 3 error.
[ PASSED ] 0 tests.
「あっ、失敗になりました」
「そうです。テストが通らなかったので、失敗を教えてくれたんです」
「「おお～」」
「仕組みはシンプルじゃが、良く出来てるのぅ」
「全くです」
――ハッ！
「サワタリさん、もしやこれは！」
「はい、フリートさん何でしょう。言ってみて下さい」
「ソースコードが残れば、どんなテストを行ったかのエビデンスになります。私は動いていることが、エビデンスと言っていたのが、お恥ずかしい限りです」
頭に手を当てて、少し恥ずかしそうに伝えてくれた。
気付いて貰えてよかった。
「そうですね。これがあれば、客観的なものになると思います。他に気付きはありませんか？」
ジン先輩に視線を移して聞いてみる。
「これがあれば、テストが、一瞬で、何度でも、簡単に、出来るぞ！！ おい、フリート、今まで諦めていたリファクタリングが出来るようになるぞ、影響範囲を全て見直せるんじゃからの！ガッハッハ」
「……確かにこれがあれば、一度テストを作ってさえしまえば、時間を使うことなく、安全性が確認できますね……！」
「お2人とも、その通りです！ 有用性を理解していただいたところで、開発にテストコードを導入していきませんか？」
「「はい、よろこんで！！」」
……デジャヴ？こんな光景が前にもあったような。
「あっ、でも、ジン先輩は異常系のテストをちゃんと書いてくださいね」
「全く、その通りですよ」
「わ、わかっとるわい。これなら俺でも書けそうだから、やってみるぞ」
「と言ったものの、最初はあまり気張らないでください。テストコードがあるということが何より重要です。中身が充実していなくても、ストレスなく、作っていけることが大切です」
「「は～い」」
プレゼンが、上手くいって良かった。
これでテストコードがある生活に戻れる……やったぜ！
ん？テスト駆動開発？ そこまではやらないよ。
今の段階ではやりすぎだし、デメリットもそれなりにあると感じているからね。
この後、3人で仲良くプログラミングを楽しんだ。
途中ムウさんが来て、インターフェースの存在価値について質問を受けた。
進捗が異常なくらい早いと思って聞いてみたら、家で読んでいたらしい。
もの凄いやる気だ。これが若さか……(年齢は知らんけど)
話を戻すと、インターフェースは中身がないので、この機能は不要ではないのかという話だ。
確かに一理あるが、多態性を支える重要な機能だ。
折角なので、4人で対話をした。
どうしてそう思っているのかを、掘り下げていくことで、ムウさんだけでなく、みんなの価値観が分かった。
持論の展開が白熱したり、自分の考えの説明を創意工夫したりするのが楽しく、充実した時間を過ごした。
時間はあっという間に過ぎてしまった。
こんな日が続けばいいなと思えた一日だった。
