What one likes, one will do well 〜好きこそ物の上手なれ〜

寄り道しながらも、最後は昔から好きな物理とプログラミングに戻ってくる。そんな男の思いをつづるブログです。

Excel VBAで使える自作のテストフレームワークを使って、実際に開発してみた。

はじめに

以前にExcel VBAで使えるテストフレームワークを作ったので、自作のフレームワークを使ってみて、実際に開発してみました。

前回の日記の記事を見ると半年以上たっていますが、2度ほど開発に使ってみて改善を加えました。

 

takus4649.hatenablog.com

 

実際に使ってみると

実際に使ってみると、すぐにエラーが発生しました。テストモジュールにsetUpを定義していなかったことが原因だったことを今でも覚えています。

テストフレームワークを作って、テストもしているとはいえ、実運用だと簡単にエラーが発生してします。あるあるですね。気づけば簡単なことですが、開発しているときは気づかないことはあります。

最初にエラーが発生した時はフレームワークは修正せずに、setUpを定義して使っていました。

その後も、クラスやモジュールごとにテストモジュールを分けようと思ったら、今度はsetUpが両方に定義してあると重複してエラーになりました。結構悲しくなりましたが、テストモジュールは1つで行うことに決めて、またしてもフレームワークは修正しませんでした。

その後もいくつかバグがあったのですが、バグリストとして残しておき、今回はとりあえず運用回避で乗り切りました。

2回目の使用

その後テストフレームワークを使う機会がまたやってきました。今回はすでにバグリストがあったので、まずはテストフレームワークの修正に入りました。

運用回避できるものもあったのですが、さすがに許せないバグもあり、直せるバグはすべて直そうと思いました。

(実はアサーションの失敗を出力するのですが、最後のアサーションの結果が出るようになっていました。しかも途中で失敗していても、最後の成功の結果が出ていたので、エラーの個所が分からず、これは開発にかなりの影響が出ると思ってバグ修正した次第です。)

すべてのバグを修正できたわけではないですが、修正したことでかなり使い勝手はよくなりました。

テストフレームワークの効果

実はこの開発は以下のような経緯をたどっています。

新規開発(以降v1と呼びます)は、テストフレームワークを使用せず、自分で結果を比較して、正しいかどうかを判定してテストをしていました。

その後の改修(以降v2と呼びます)で、自作のテストフレームワークを適用したのですが、v1のテストはそのままにして、v2の新規機能分だけテストフレームワークを使用しました。テストフレームワーク分は快適だったのですが、v1に影響が出る部分で再テストするときは使い勝手が違って不便でした。

その後の改修(以降v3と呼びます)で、全面的に自作のテストフレームワークを適用して、v1のテスト部分もテストフレームワークで書き直しました。

v1のテストを書き直した時に、テストコードがシンプルになって、読みやすくなって、テストフレームワークの威力を感じました。テストコードは半分以下になったと思います。また結果の確認も簡単になり、開発がかなりスムーズに進むようになりました。

おわりに

自作のテストフレームワークは、ケントベックのテスト駆動開発入門を読んで、自分で作ってみたのですが、軽量なフレームワークなのに、その効果は絶大だと思いました。しかもxUnitは、色んな言語に移植されているので、使い勝手が言語が違ってもあまり変わらないというのも素晴らしいと思います。

何よりちまちま自分でテストコードを書いて比較して、とやるよりテストフレームワークを使うことによって効率が格段に上がることを体験しました。

自分で作ったテストフレームワークが自分で実感できるほどの効果があり、とても嬉しくも感じました。

今回の開発を踏まえてのv1.0.2をリリースしましたので、Excel VBAを使って開発している人がいましたら、ぜひご活用ください。

 

github.com