先日ChromeのExtensionを2つほど作成しまして、まぁ自分が欲しかったから作ったのですけれども、テクニック的な興味はExtension自体にはなく
- 自動テストとTDD（テスト駆動開発）
- Gitによるバージョン管理とGitHubでのソースの共有
の2点にありまして、せっかくですので使ってみての感想をつらつらと書き残しておこうかと思います。
ちなみに作成したExtensionは下記になります。
Chrome Extension「ato-ichinen」をChrome Web StoreとGithubに公開しました | 諸葛亮孔明もびっくりですわ のブログ
Chrome Web Store: https://chrome.google.com/webstore/detail/pojaolkbbklmcifckclknpolncdmbaph
GitHub: https://github.com/amazedkoumei/chrome-ext-ato-ichinen
Chrome Extension「My はてブ Search」をChrome Web StoreとGithubに公開しました | 諸葛亮孔明もびっくりですわ のブログ
Chrome Web Store: https://chrome.google.com/webstore/detail/fagdddhhkjdpchaokeceilckcefmbeil
GitHub: https://github.com/amazedkoumei/chrome-ext-my-hatebu-search-in-google
自動テスト / TDDについての感想
GitHubにあげてから何回かBugFixをPushしたのですが確かに楽だったのいうのが率直な感想です。
例えば正規表現に不具合など、自動テストを書いてなかった場合にはすでにテスト済みのケースの再試験も必要となりますし、とてもストレスを感じる修正ですが、自動テストを書いてあったおかげで思いっきって修正をかけることができました。
修正手順としましても
- 不具合のあったケースのテストを記述
- テストが失敗することを確認
- 本体を修正
- テストが成功することを確認
といういわゆるTDD（テスト駆動）な直し方を、テスト駆動でやるねん( ノ゜Д゜) と肩肘はることなく自然とそうしました。それが一番楽な修正方法でしたから。
自動テスト / TDDに関するトピックでよく話題にのぼるカバレッジ率ですが、こちらについてもよく言われるように決して100%を目指す必要はないと感じました。
自動テストを、書くべき・さぼるべき、のひとつの基準としては、Webアプリケーション開発の経験が長いためそれを例に書きますけども、「ブラウザから視線を切らねば確認できない箇所」というのがまず当てはまるかな、と。神はディテールに宿ると言いますが、ストレスもディテールに宿るのでありますよ。
具体的な例をあげますと
- データベースのCRUD
- ログ出力
- ファイルの入出力
- メール送信
あたりでしょうか。クリックしてDB覗いて、クリックしてログを覗いて、クリックしてメーラー覗いてとかもうね。。ストレスはディテールに宿るのでありますよ。
これに加えて、ちょろ修正に対して膨大なケースの試験が発生してしまうもの。
- 正規表現
- 入力値のValidation
あたり。
インジェクション対策の試験であるとか、発生させるのが困難な例外処理の試験であるとか、ブラウザ以外のツールを使わねばならない面倒な試験を、ただエディタに文字列を打ち込むだけで繰り返し実施できる環境ができてしまうのは素敵だなと感じた次第です。
BugFixではなく新機能作成の際にテスト駆動にこだわる必要はあまり感じませんでした。
定型の業務システムのようにガチガチに仕様が固まっている場合はTDDで開発するのが幸せなんでしょうけども、そうでないものについては、とりあえず動くものを作り、試行錯誤して、うむ、これで行こうと大方針を決めてからテストを作成しないと、テストがお荷物になってしまうかなと。
つまりは自動テストが試行錯誤の味方になってくれる適切な作成タイミングというものが確かにあって、そのタイミングで作成するのが幸せなはずなんですけど、、、ちょっとそのタイミングを言語化するのは難しいですな（・ω・｀）
以上、なにをいまさらな話ですけど、そう思って、書き残したいとも思ったんだから堪忍してーな。
ちなみにExtensionの開発で使ったqunitのハマりどころはこちらで別途エントリしておりますのでもしよろしければ。
→ JavascriptのUnitテストライブラリ「qunit」のtest()メソッドとasyncTest()メソッドとstart()メソッドについて
Gitによるバージョン管理 / GitHubでのソースの共有 について
これもまぁなにをいまさらな話なのですが、ローカルにリポジトリがあるのはとても幸せだなと感じました。
CVSやSubversionを使ってのチーム開発ですと、やはり中途半端なものをみんなが使うサーバにコミットするわけにはいきませんから、コピペでバックアップをとってDiffツールで比較するとか、ちょｗいま2012年なんですけどｗｗみたいなことをせねばならず、それはそれはストレスなわけですが、Gitの場合はローカルにリポジトリがあるわけですから、もうガンガンと誰を気にすることなくコミットできてしまうわけです。
ちなみに今回ぼっちで開発しているので、上記の感想は完全に妄想です。しかしだからと言ってぼっちの妄想力なめんなよこの野郎（・ω・｀）
GitHubについてはまだよく分からない部分もありますが（自作自演のPullRequestはしてみたけども！ひとりで！Issueも切って！泣いたりなんかしなかったけどね！）、チケット管理機能 (Issuesタブ) やWiki (Wikiタブ)、branch相関図 (Networkタブ) などなどありまして、いわゆるオープンソースでない企業様内での開発も、イントラ内にマイサーバを立てるのではなくPrivateリポジトリ使って開発していった方が幸せになれるのではなかろうかと思った次第です。安いし。
最後に
プログラムを書いていて一番ストレスを感じるのは、やはり動いているものを壊す時でして、自動テストもGitもそのストレスを大いに取り払ってくれる素敵なツールだと感じました。
UIであるとかUXであるとかが取り沙汰され、クライアントもどんどんリッチになっている昨今、ノンストレスで試行錯誤できる環境は必須かなと思う次第です。
取り除けるのは小さな小さなストレスかもしれませんが、それを積み重ねてストレスゼロに近づければ、それはそれは幸せではないですか。
個人的な開発環境につきましても小さな小さなストレスを取り除くべく、日々小さな小さな工夫をこらし、少しでもソースに集中できる環境を構築するために時間と労力をつぎ込んでおります。
プログラマにご連絡の際には極力メールで頂けると喜ばれると思います。