今年の9月頃、自分はJUnitの歴史を初めて知り、深く反省することとなりました。
今日はJUnitの歴史を整理して、おまけとして自分が反省したことを書いておきます。
JUnitの歴史
以下常体。
創始者はKent Beck。
Kent Beckは少し変更してすぐに検証する、というインクリメンタルな開発を1992年頃に進めていた。
しかし、自動テストの大ファンだったKent Beckにとって、検証が自動化されていないことは課題だった。
そこで、当時Smalltalkで開発していたKent Beckは、Smalltalkの構造をヒントにして単体テストを編成して実行するための単純なフレームワークを構築した。
構築したフレームワークは、Kent BeckとKent Beckのクライアントや支援者(Martin Fowlerなど...)に展開された。*1
これにより、Kent BeckとKent Beckのクライアントや支援者は、サブセット(フルセット)のテストを迅速に実行できるようになった。
その後、チューリッヒからOOPSLA97開催地のアトランタに向かう飛行機で、Erich GammaとKent Beckはテストフレームワークを当時新しい言語だったjavaで作成した。
この時作成されたテストフレームワークがJUnitの起源となっている。
JUnitの歴史を知って自分が反省したこと
JUnitの歴史を知って、自分は深く反省しました。
JUnitを「プロダクションコードを全て書き終えてレビューしてもらった後、メソッドレベルでバグがないことを確認するもの」と捉えていたせいで、JUnitを誤用していたことに気が付いたからです。
この歴史を知るまでの自分は、JUnitの恩恵を感じつつも、使いにくさというも同時に感じていました。
大きなメソッドをテストするために大量のモックを作って頑張ってJUnitを作るものの、JUnitは直ぐに壊れてしまい次第に使われなくなっていたのがその理由です。
果たしてJUnitに意味があるのだろうか、JUnitがもう少し壊れにくい仕組みになればいいのに、と思っていました。
しかし、JUnitの歴史を知って、実際の所JUnitは何も悪くなく、自分がJUnitを使う理由を正しく理解せずに使用していたせいで、上手く使えていなかっただけであることに気が付きました。
JUnitの歴史に書いた通り、JUnitはあくまでもインクリメンタルな開発サイクルを回す上で生まれたものであり、過去の自分のような大きく作り大きく検証する開発者を想定して作られていなかったのです。
これは、巷で流行しているからスクラムを取り入れて失敗し、やっぱりスクラムは上手くいかないと嘆くのと同じことで、ソリューションに飛びついただけの危険な行動だったと深く反省しました。
流行りの技術は魅力的で知的好奇心が擽られるのですが、技術が生まれたコンテキストや解決したい課題を意識して学ぶことを、常に忘れないようにしたいです。*2
参考記事
『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。：An Agile Way：オルタナティブ・ブログ
