Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
Firefoxのテスト環境が…… - Dec 10, 2008
Browser chrome tests - MDC 見ながらなんとか環境整えてビルドしてテスト実行して……という風な事をしてみたけど、テスト結果のあまりのわかりにくさに閉口した。しかも一個テストがこけたら後の物も続けて失敗するし。クリーンなプロファイルで起動してくれるのはいいけど、あとがもうメタメタすぎて、とても常用（？）する気にならないよ……
というわけでUxUの次のテーマはFirefoxのソースツリー上にある自動テストを実行する機能ということにしたいと思います。
- イベント関係のユーティリティのエイリアスを作る。
waitForExplicitFinish()とfinish()での非同期テストをサポートする。- 実行コンテキストを新しく開いたブラウザウィンドウに固定する（テストごとにウィンドウを破棄）。
この辺が鍵でしょうか。
追記。概要をつかむために説明を翻訳した。これによると、「browser_*.js」という名前のファイルだけがブラウザ用のテストとして認識されるようなので、ファイル名がこのルールに一致していたら上記のような特別な処理を行うようにする、という感じで行けそう。
UxUを使った、自動テストを伴うデバッグ手法の実践 - Nov 18, 2008
UxU（UnitTest.XUL）を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)
XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。
リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。
よくある風景 - Nov 15, 2008
XUL/Migemoの動作で怪しい所を見つける→再現条件確定→その条件下でのテストを行うためのUxUのテストケースを作成→何かちゃんと動かない→UxUのバグ発見→抜本的修正開始→途中で疲れて寝る→抜本的修正続き→やっとチェックイン→XUL/Migemoのテストを書く気力がなくなってる→それでもめげずにテスト書き再開→UxUの別の問題発覚→心が折れかける（今ここ）
UxUこっそり改良進行中 - Oct 26, 2008
UnitTest.XULとかUxUとかうずとかいうアレ。サイトの方は長らく放置してますが、地味に作業してます。
- テスト専用のプロファイルを指定してテストを実行する機能。Ruby on Railsのfixtureみたいな。
- ユーザプロファイル内でなくアプリケーションのインストール先の方に自動インストールする機能。
- テストの実行結果をファイルに保存する機能。
- Thunderbirdでメール送信のテストをしたい、という時のために、メールを送信する処理を実行したら、実際にはメールを送信しないでローカルのどこかに溜め込んで、その内容を普通に文字列として取れる仕組み。Ruby on Railsのメール関係のテストの仕組みのような。
プロファイルを指定してテストを実行する、というのはずっと前からやりたいと思ってた。これができると機能テストとか結合テストとかいう段階のテストが圧倒的に楽になる……はず。
UxUの自己テスト - Jul 17, 2008
UxUの自己テストを（現実逃避に）ようやく書き始めてみている。今まで無かったのかよって怒られそうだけど……
アサーションのモジュールのテストとかテストケースのテストとか、書いてて頭がこんがらがってくる。
MochiKitのテスト機能 - Jul 15, 2008
MochiKit見てみた。
これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……
仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの？」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった（今もまだよく分かってないかもだけど）。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな？」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。
自動テスト - Apr 25, 2008
regression（後退バグ。修正のために加えた変更が原因で新たな問題が発生すること）のせいで体力・精神力を消耗する事が重なり、自動テストドリブンな開発の重要さを身に染みて感じた。プレゼンでも言ったけど、「やってりゃ良かった」と後悔してばかりだ。まさかこんなに手こずる羽目になるとは当初は思っていなかったから。
自動テストはregressionの発生を防ぐ（正確には、regressionを残したままでいることを防ぐ）素晴らしいメソッドだ。と今になって改めて思う。
でも、どんなコードでも機械的に自動テストにかけられるわけではない。機械的に自動テストを実施するには、自動テストを実行しやすい設計になっていなければならない。自動テストを実行しやすい設計とは、粒度が小さい＝オブジェクトやらメソッドやらが可能な限り細かい単位で分割されている設計のこと。テスト対象となる部品自体が可能な限り自己完結していて、外部的な要素は必要に応じてすべてパラメータとして与えるようになっていること。横着して一つの関数内からグローバル変数やら何やらを参照しまくっていると、その関数のロジックそのものをテストすることができない。
そういうわけで、自動テストドリブンな開発には気を遣わなければならない。気を遣わないといけないから気力を消耗する。だから、せずに済むのなら、しないままでいたい。でも、そう考えているうちに「自動テストを作成する＆テストを実施しやすい設計にするコスト」と「やっつけで作って、その都度メンテナンスするコスト」の関係が、「前者＞後者」だったのがいつの間にか「前者＜後者」に逆転してしまうようになっていて、メチャメチャ後悔することになる。
今まで自分のやってきたことは9割方、自動テスト無しでもどうにかやってこれていたし、そもそも、自動テストの重要性とそのための設計の指針が分かった今改めて見返してみても、自動テスト化することが困難な物が多かった、と思う。だから、自動テストを前提にしてコードを書くという習慣が身についていない。自動テストが最初から不可能な事が多かったから、自動テストのできない設計にするしかなかったから、自動テストのできない設計にすることが当たり前になってしまっている。
でもいい加減、その悪習を断ち切らなければならない。25歳ももうすぐ終わりの、四捨五入すれば三十路の、今更も今更で手遅れ感がとても強いけれども、やらなければいけない。今まで自分がやってきた方法は通用しないということを自覚しないといけない。できて当たり前の事が今まで全くできていなかったという事、本当はこの面子の中で飛び抜けて一番遅れているという事、それなのに対等であるように勘違いして思い上がっているという事、今まで他人事だと思ってた「ダメな人の典型」に自分がまったく当てはまっているという事、全部認めないといけない。
そういうわけでとりあえずUxUはマジオススメ。
自動テスト - Jan 01, 1970
regression（後退バグ。修正のために加えた変更が原因で新たな問題が発生すること）のせいで体力・精神力を消耗する事が重なり、自動テストドリブンな開発の重要さを身に染みて感じた。プレゼンでも言ったけど、「やってりゃ良かった」と後悔してばかりだ。まさかこんなに手こずる羽目になるとは当初は思っていなかったから。
自動テストはregressionの発生を防ぐ（正確には、regressionを残したままでいることを防ぐ）素晴らしいメソッドだ。と今になって改めて思う。
でも、どんなコードでも機械的に自動テストにかけられるわけではない。機械的に自動テストを実施するには、自動テストを実行しやすい設計になっていなければならない。自動テストを実行しやすい設計とは、粒度が小さい＝オブジェクトやらメソッドやらが可能な限り細かい単位で分割されている設計のこと。テスト対象となる部品自体が可能な限り自己完結していて、外部的な要素は必要に応じてすべてパラメータとして与えるようになっていること。横着して一つの関数内からグローバル変数やら何やらを参照しまくっていると、その関数のロジックそのものをテストすることができない。
そういうわけで、自動テストドリブンな開発には気を遣わなければならない。気を遣わないといけないから気力を消耗する。だから、せずに済むのなら、しないままでいたい。でも、そう考えているうちに「自動テストを作成する＆テストを実施しやすい設計にするコスト」と「やっつけで作って、その都度メンテナンスするコスト」の関係が、「前者＞後者」だったのがいつの間にか「前者＜後者」に逆転してしまうようになっていて、メチャメチャ後悔することになる。
今まで自分のやってきたことは9割方、自動テスト無しでもどうにかやってこれていたし、そもそも、自動テストの重要性とそのための設計の指針が分かった今改めて見返してみても、自動テスト化することが困難な物が多かった、と思う。だから、自動テストを前提にしてコードを書くという習慣が身についていない。自動テストが最初から不可能な事が多かったから、自動テストのできない設計にするしかなかったから、自動テストのできない設計にすることが当たり前になってしまっている。
でもいい加減、その悪習を断ち切らなければならない。25歳ももうすぐ終わりの、四捨五入すれば三十路の、今更も今更で手遅れ感がとても強いけれども、やらなければいけない。今まで自分がやってきた方法は通用しないということを自覚しないといけない。できて当たり前の事が今まで全くできていなかったという事、本当はこの面子の中で飛び抜けて一番遅れているという事、それなのに対等であるように勘違いして思い上がっているという事、今まで他人事だと思ってた「ダメな人の典型」に自分がまったく当てはまっているという事、全部認めないといけない。
そういうわけでとりあえずUxUはマジオススメ。
自動テスト - Jan 01, 1970
regression（後退バグ。修正のために加えた変更が原因で新たな問題が発生すること）のせいで体力・精神力を消耗する事が重なり、自動テストドリブンな開発の重要さを身に染みて感じた。プレゼンでも言ったけど、「やってりゃ良かった」と後悔してばかりだ。まさかこんなに手こずる羽目になるとは当初は思っていなかったから。
自動テストはregressionの発生を防ぐ（正確には、regressionを残したままでいることを防ぐ）素晴らしいメソッドだ。と今になって改めて思う。
でも、どんなコードでも機械的に自動テストにかけられるわけではない。機械的に自動テストを実施するには、自動テストを実行しやすい設計になっていなければならない。自動テストを実行しやすい設計とは、粒度が小さい＝オブジェクトやらメソッドやらが可能な限り細かい単位で分割されている設計のこと。テスト対象となる部品自体が可能な限り自己完結していて、外部的な要素は必要に応じてすべてパラメータとして与えるようになっていること。横着して一つの関数内からグローバル変数やら何やらを参照しまくっていると、その関数のロジックそのものをテストすることができない。
そういうわけで、自動テストドリブンな開発には気を遣わなければならない。気を遣わないといけないから気力を消耗する。だから、せずに済むのなら、しないままでいたい。でも、そう考えているうちに「自動テストを作成する＆テストを実施しやすい設計にするコスト」と「やっつけで作って、その都度メンテナンスするコスト」の関係が、「前者＞後者」だったのがいつの間にか「前者＜後者」に逆転してしまうようになっていて、メチャメチャ後悔することになる。
今まで自分のやってきたことは9割方、自動テスト無しでもどうにかやってこれていたし、そもそも、自動テストの重要性とそのための設計の指針が分かった今改めて見返してみても、自動テスト化することが困難な物が多かった、と思う。だから、自動テストを前提にしてコードを書くという習慣が身についていない。自動テストが最初から不可能な事が多かったから、自動テストのできない設計にするしかなかったから、自動テストのできない設計にすることが当たり前になってしまっている。
でもいい加減、その悪習を断ち切らなければならない。25歳ももうすぐ終わりの、四捨五入すれば三十路の、今更も今更で手遅れ感がとても強いけれども、やらなければいけない。今まで自分がやってきた方法は通用しないということを自覚しないといけない。できて当たり前の事が今まで全くできていなかったという事、本当はこの面子の中で飛び抜けて一番遅れているという事、それなのに対等であるように勘違いして思い上がっているという事、今まで他人事だと思ってた「ダメな人の典型」に自分がまったく当てはまっているという事、全部認めないといけない。
そういうわけでとりあえずUxUはマジオススメ。
自動テスト - Jan 01, 1970
regression（後退バグ。修正のために加えた変更が原因で新たな問題が発生すること）のせいで体力・精神力を消耗する事が重なり、自動テストドリブンな開発の重要さを身に染みて感じた。プレゼンでも言ったけど、「やってりゃ良かった」と後悔してばかりだ。まさかこんなに手こずる羽目になるとは当初は思っていなかったから。
自動テストはregressionの発生を防ぐ（正確には、regressionを残したままでいることを防ぐ）素晴らしいメソッドだ。と今になって改めて思う。
でも、どんなコードでも機械的に自動テストにかけられるわけではない。機械的に自動テストを実施するには、自動テストを実行しやすい設計になっていなければならない。自動テストを実行しやすい設計とは、粒度が小さい＝オブジェクトやらメソッドやらが可能な限り細かい単位で分割されている設計のこと。テスト対象となる部品自体が可能な限り自己完結していて、外部的な要素は必要に応じてすべてパラメータとして与えるようになっていること。横着して一つの関数内からグローバル変数やら何やらを参照しまくっていると、その関数のロジックそのものをテストすることができない。
そういうわけで、自動テストドリブンな開発には気を遣わなければならない。気を遣わないといけないから気力を消耗する。だから、せずに済むのなら、しないままでいたい。でも、そう考えているうちに「自動テストを作成する＆テストを実施しやすい設計にするコスト」と「やっつけで作って、その都度メンテナンスするコスト」の関係が、「前者＞後者」だったのがいつの間にか「前者＜後者」に逆転してしまうようになっていて、メチャメチャ後悔することになる。
今まで自分のやってきたことは9割方、自動テスト無しでもどうにかやってこれていたし、そもそも、自動テストの重要性とそのための設計の指針が分かった今改めて見返してみても、自動テスト化することが困難な物が多かった、と思う。だから、自動テストを前提にしてコードを書くという習慣が身についていない。自動テストが最初から不可能な事が多かったから、自動テストのできない設計にするしかなかったから、自動テストのできない設計にすることが当たり前になってしまっている。
でもいい加減、その悪習を断ち切らなければならない。25歳ももうすぐ終わりの、四捨五入すれば三十路の、今更も今更で手遅れ感がとても強いけれども、やらなければいけない。今まで自分がやってきた方法は通用しないということを自覚しないといけない。できて当たり前の事が今まで全くできていなかったという事、本当はこの面子の中で飛び抜けて一番遅れているという事、それなのに対等であるように勘違いして思い上がっているという事、今まで他人事だと思ってた「ダメな人の典型」に自分がまったく当てはまっているという事、全部認めないといけない。
そういうわけでとりあえずUxUはマジオススメ。