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

モブプロ(モブプログラミング)やってみた。Qiita

Qiitaにモブプロ(モブプログラミング)やってみた - Qiitaの記事を投稿しました。

初めてのモブプロだったのですが(ペアプロもやったことがない)、楽しくプログラミングができ、可能性を感じる手法だと思いました。

今回は知らない人が集まってやったのですが、今度は知っている仲間とやってみたいと思います。

 

qiita.com

2017年5月のつぶやき

2017年3月のつぶやき

[https://twitter.com/takus4649/status/846380311298506752:embed#"Cloud9でTensorFlowのチュートリアルで畳み込みニューラルネットワーク(CNN)をやってみた~手書き画像の分類~ [Python] on @Qiita https://t.co/oEfeMnYU5e"]

Qiitaに記事を投稿しました。Cloud9でTensorFlowのチュートリアルで畳み込みニューラルネットワーク(CNN)をやってみた~手書き画像の分類~

QiitaにCloud9でTensorFlowのチュートリアルを実装した記事を書きました。

 

qiita.com

 

 

下記の前回の記事の続きで、前回は初心者向けのMNIST。今回は専門者向けのMNISTです。私は専門者ではないですが。。。

合わせて下記の記事およびコードも見直しました。

 

takus4649.hatenablog.com

 

やってみてコードを実装するのが一番の理解の早道だと感じます。何でもそうですが、自分で工夫したり、苦労したりするのが一番理解が深まります。次はチュートリアルではなく自分のオリジナルを実装していきたいと思います。

 

twitterをはてなブログに投稿するgemを改善


以前にtwitterのつぶやきをブログに残していきたいと思って、gemを作成しました。

 

takus4649.hatenablog.com

 

最初は毎日ブログにつぶやきを投稿していたのですが、twitterの利用頻度が増えるとブログ記事がつぶやきで埋まってしまうので、1ヶ月に1回の投稿に変えました。その時gemを直していたのですが、急いで直したこともあり使い勝手がよくなかったです。

自分の使い方に合わせてgemを修正して、やっと使いやすくなりました。自分用ですが、改善した内容をまとめておきます。

ちなみに投稿はslack経由でrubotyに実行してもらっています。

使い勝手が悪かった点は以下の2点です。

1つ目は、

post_between 開始日 最終日

という形の命令が長く日付指定が面倒だったという点につきます。

postという形の命令にしたかったのですが、毎日の投稿用使っていたため長い命令になっていました。そこで今や使っていない毎日の投稿処理をなくし、postで前月の投稿するように変更しました。

実処理はruboty用のgemとは、別のgemとして作成していたため変更は楽でした。

2つ目は、ruboty-twitterToHatenaからEditTwitterとPostToHatenaの2つのgemを呼んでいました。でも2つに分ける必要ないと思い統合しました。2つのgemを使っていた時はrubotty-twitterToHatenaで制御する処理が必要になっていたのですが、統合することで1つのメソッドを呼ぶだけのシンプルな作りになりました。

PostToHatena1つに統合したのですが、それに合わせてリファクタリングも実施持しました。DRY原則を適用して重複の部分を大きく減らせました。

動いているものを変更して改善するのは重い腰を上げないといけないのですが、改善した後の爽快感は最高です。

こう感じる事ができるようになったのは、テストを書くようになった事、リファクタリングをするようになった事が大きいと思います。テストなしだとやりたいとは思いません。

みんなもテストを書いてリファクタリングしましょう。

一応コードを公開しておきます。

github.com

 

2017年2月のつぶやき