Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/248: 1 2 3 4 5 6 7 8 9 »

モックが必要な場面、モックが有効な場面 - Aug 11, 2010

モック(Mock)とスタブ(Stub)の違いがよく分かってなかったんだけど、何が違うのか、そしてモックはどう使う物なのかということを、すとうさんに教えてもらって今更理解した。あとで会社のブログに書くつもりだけど、メモとして要点だけまとめておく。

  • テストは基本的に、粒度の細かいブラックボックステストにした方がいい。
    • 内部に持ってる隠しプロパティの値が正しいかどうか?という風な実装べったりのテストは、実装の変更に非常に弱い。
    • なので、関数の返り値だけ見て検証できるような設計が、自動テストしやすい設計という意味で「良い設計」と言える。
  • しかしブラックボックステストには限界がある。
    • 色々な副作用を伴う機能だったり、非同期で処理するような機能だったり、1回の実行で複数の状態を遷移する機能だったり、という風に、単純に関数の実行→返り値を検証 とするだけではテストできない機能もある。
      • ユニットテストのレベルでそういう機能があるのは設計が良くない証拠なので、こういう物は関数を細かい単位に解体して、単純に関数の実行→返り値を検証 というブラックボックステストを行えるような設計に直すべき。
      • 処理待ちしてやりさえすればいいような場合、処理待ちのための機能を持ったテスティングフレームワークを使うと、単純な非同期処理なら簡単にブラックボックステスト化できる。
    • 色々な副作用を伴う機能や、状態遷移があるような機能をブラックボックステストできるようにしようと思うと、「内部で状態の遷移のログを取っておいて、最後にそのログの内容が期待通りになっているかどうかを検証する」という風な形にならざるを得ない。
      • ということをやろうと思うと、本番用のコードの中に「ログ取り用の処理」のような「実際に使う場面では無駄」なコードが増えていってしまう。
      • テストしやすくするためにテスト対象の実装に手を入れるのはよくあることだし、そうやって手を入れた結果として関数が小さな単位に分割されていったり関数名と入出力の対応が分かりやすくなっていったりするのなら、それによって動作が安定するようになったりコードのメンテナンス性が高くなったりするから、いいことだ。でも「テストのためだけの実装」が増えていって、動作が不安定になったりコードのメンテナンス性が落ちたりするのでは本末転倒だ。
  • ブラックボックステストにし続けるためのコストが、本来の実装に悪影響を及ぼすようなレベルになってしまったら、そろそろホワイトボックステストに移行していい頃合いだ。
    • 検証対象の機能の粒度が大きくなってくると、これはもう避けられない事と考えた方がいい。

自分は今まで、とりあえずユニットテストに注力していて、ある意味脅迫観念的な勢いで、ブラックボックス度合いを高くする事を心がけてた。今まではそれでだいたい問題なかった。でも最近になって、ブラックボックステストにしようとすると無理があるというケースにぶち当たるようになった。1つの機能の中でコロコロと遷移する内部状態を、どうにかして検証したいというようなケースが出てきた。

それですとうさんに相談したら、そういう時はモックを使えばいいと言われた。でも、話を聞く限りだとモックというのはテスト対象の実装の中の処理の流れを追う物のようなので、それじゃブラックボックステストにならないじゃないかと思った。それをそのまま言ったら、確かにテストはできるだけブラックボックステストになってた方がいいけど、機能テストやインテグレーションテストのような粒度の大きな単位のテストでは、処理の中で起こる様々な出来事や副作用を色々モニタリングして、すべての処理が期待通りに動いているかどうかを検証しないといけないから、必然的にホワイトボックステストにならざるを得ないと言われた。

それを聞いて、目の覚めるような思いをした。そうか、ブラックボックステストとホワイトボックステストの使い分けはそこが基準になるのか、と。今まで自分がホワイトボックステストを書かずに済んでいたのは、状態の遷移を伴うような機能を作る必要がなかったからだったんだ、テストをどうも書きにくいなあと思っていた機能は本当はホワイトボックステストにしたほうがいい物だったんだ、と。

そんなわけでUxUにモックの機能を実装した

「JavaScript Mock」で検索するとJSMockjqmockが上位に出てきたので、最初はそれらを参考にするように(メジャーな実装があるんだったらそれをそのまま取り入れるなりAPIを合わせるようにするのが望ましい)と言われたんだけど、ドットで繋げるメソッドチェインの記法がガンガン出てきて頭パンクした。

もう少し下の方までスクロールするとMockObject.jsというのが出てきて、こっちはファイル全体で3KBに満たない小さなライブラリなので、まずはここから始めることにした。何せコードが短いから、読むのもそんなに苦にはならない。モックの概念を言葉で説明されてもさっぱりだったけど、一通りの処理の流れを見たら、「モックというのは一体何をやらなきゃいけないのか」「どういう振る舞いが期待されているのか」ということがよく分かった。

MockObject.jsと同等の機能を一通り実装した後でもう一度JSMockの方を見たら、なるほどこれはこういう意味だったのかというのがやっと分かった。サンプルコードを見ても、モックという物の意味をそもそもよく知らない時点では、どこからどこまでがJSMockの部分なのかさっぱり分からなかったんだよね。ということで、MockObject.jsに加えてJSMock互換のAPIも付け加えてみた。jqunitの方は……もう別言語だからシラネ。

あと有名なのはJsMockito? これも頑張ったらできるかなあ、というかMITライセンスだしそのままぶち込んだ方が早いか……

ツリー型タブの自動テスト - Feb 12, 2009

書き始めた。

最近、恐怖症っていうか神経症っていうか……自動テストで検証されてない事が怖くて仕方ない。一通りテストを書き終えるまで、次をリリースするのが怖い。リリース工程をとても億劫に感じてしまって、どうにかしてそれを乗り越えてやっとリリースしたと思ったら、しょうもないregressionがあることに気がついて、またあの面倒なリリース工程をやらないといけないのかと思うと気が重くなって。

追記。とかなんとか言いながら結局テスト未完のままリリースしてしまった。

テストがあるからってバグがない訳ではない……XUL/Migemoもまだまだモロモロと障害が見つかってる。ただ、自動化のプロセスがほぼできあがってるので、新たに問題がおこるケースが見つかったら、それをテストケースに追加して、コードを修正して、全体のテストが完遂すること(=regressionが無いこと)を確認して、過去に自分が把握してた範囲についてはある程度の自信を持ってリリースできる。自動化ができてないと、その自信を持てない。直したと思った物がすぐ後ろから崩れてるかもしれないという恐怖に駆られる。

MDCの自動テスト関係のドキュメントの翻訳 - Dec 12, 2008

UxUにFirefox用のテストケースを実行する機能を加えるにはそもそもFirefox用のテストケースの仕様を調べないといけない、ということでそこら辺の文書をあたってみたら全然翻訳されてなかったので、次にパッチを書く時(あるのか?)のための勉強も兼ねて翻訳しまくってる。

アサーション用の関数の引数の順番の理解を間違えていた……というか元の英語の文書で「thingAとthingBを比較」とか酷い書かれ方になってたので、SimpleTestのソースを確認して、「actualValueとexpectedValueを比較」という風に読んだら意味が分かるようにしておいた。こういう事があると、確かに須藤さんの言う「駄目なことはできないような設計」というのは重要なのだなあと改めて思う。

「テストハーネス(test harness)」って一般的な用語なんだろうか。よく分かんなかったから全部「テスト実行環境」って訳した。問題あるようだったら誰かが勝手に直してくれることに期待してる。→やっぱりテストハーネスで統一した。一応訳註も入れてるけど。

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の自己テスト - Jul 17, 2008

UxU自己テストを(現実逃避に)ようやく書き始めてみている。今まで無かったのかよって怒られそうだけど……

アサーションのモジュールのテストとかテストケースのテストとか、書いてて頭がこんがらがってくる。

Selenium、Selenium IDE - Jul 16, 2008

試してみた。

SeleniumはWebアプリケーション用のクロスブラウザな自動テストツールで、独自の書式または好みの開発言語でテストケースを書いて、Webアプリケーションの機能テストを行える。Selenium IDEを使うとFirefox上での操作を記録して(何もないところでクリックするという風な操作も記録される)、Selenium用のテストケース(の雛形)まで生成してくれる。

あーこれはいいわー。Webアプリ開発やるなら絶対お勧めだと思う。FirefoxでSelenium IDE使ってテストケース作って、それをエクスポートして他のブラウザでも自動テスト、ということもできるようだし。

ちゃんとドキュメント見てないからよく分かってないけど、ユニットテスト(単体テスト)より機能テスト(結合テスト)に特化してるような気がした。単体テストには別のツールを組み合わせることになるんだろうか。あと当然だけどFirefoxのアドオンの自動テストには使えない。

iMacros - Jul 16, 2008

iMacrosも試してみた。

リンクをクリックしたとかフォームに文字列を入力したとかの操作を記録して再生できるんだけど、これは完全にWebサービスの操作を記録・再生するためだけのものっぽい。アサーションもないようだから自動テスト用には使えないなあ。サーバ側のテストには使えるかもだけど。

MochiKitのテスト機能 - Jul 15, 2008

MochiKit見てみた。

これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……

仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの?」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった(今もまだよく分かってないかもだけど)。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな?」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。

Page 1/248: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき