SlideShare a Scribd company logo
Takuto Wada (@t_wada on Twitter)
Nov 20, 2010 @ Firefox Developers Conference
10+1 things you should know
about javascript testing
JavaScript をテスト
するときに考える
10のことがら+1
Who am I ?
•TDD guy in Japan.
•@t_wada on Twitter
•twada on github
大事なことを最初に
=> 宣伝
First things first.
=> Ad.
97 Things Every Programmer Should Know
日本人寄稿者
(邦訳オンリー)
@omo2009
@m_seki
@hyoshiok
@miyagawa
@hotchpotch
@dankogai
@yukihiro_matz
@t_wada
97 Things Every Programmer Should Know
日本人寄稿者
(邦訳オンリー)
@omo2009
@m_seki
@hyoshiok
@miyagawa
@hotchpotch
@dankogai
@yukihiro_matz
@t_wada
12月中旬発売
よろしくおねがいします
Yoroshiku onegai shimasu
1.「全部をテストする」
ことはできない
You can’t test “everything”.
「全部をテストする」
ことはできない
•使い心地、綺麗な見た目のテスト
は人間にしか出来ない
•Usability, look and feel can be
tested only by manually.
「全部をテストする」
ことはできない
•「人間でなくとも出来ることをテ
ストにサポートさせる」と考える
•Other aspects can be tested
automatically, so let computers
do them.
2. 目視を可能な限り
減らす
reduce visual inspection
as much as possible.
目視を可能な限り減らす
•目視必須の所と目視不要の所を分
ける。
•Separate code that must be
inspected visually from other
code.
目視を可能な限り減らす
•目視不要の部分が増えるほど、人
間の手間が減る
•The more you automate the
non-visual testing, the more
benefit you gain.
3. 同期処理と
非同期処理を
分ける
divide synchronous part
from asynchronous part.
同期処理と
非同期処理を分ける
•非同期処理はテストが難しく、テス
ト実行時間もかかりがち
•Asynchronous tests tend to be
complex and time-consuming.
•コードの非同期処理部分(イベント
ハンドラ)を最小にして、同期的に
テストできる部分を増やす
•Maximize amount of code that
can be tested synchronously, by
minimizing asynchronous part of
code. (e.g., event handlers)
4. 内部構造を
隠 しすぎない
Avoid too much
information hiding.
内部構造を
隠 しすぎない
•例えば、テストですり替えたいハ
ンドラに匿名関数を使わない
•For example, avoid using
anonymous functions for event
handlers.
•内部の接合点をテストから見える
ように、差し替えられるように設
計する
•Pay attention to Seams and
Interception Points . Provide
enabling points for Mocks/
Stubs. (see WEwLC)
5. カスタムイベントで
粗結合化する
Decouple components
by using custom-events.
カスタムイベントで
粗結合化する
•イベント発火元と受取り側の結合
度を減らす
•Decouple event handlers from
event sources, by using
custom events.
カスタムイベントで
粗結合化する
•デザイン変更、DOM構造の変更
からロジックを隔離する
•Make code independent from
Design/DOM structure change.
6. 先人の設計に学ぶ
standing on the
shoulders of giants.
先人の設計に学ぶ
•書籍を紐解き、先人の知恵に学ぶ
•Read good books. Learn the
wisdom and culture from these
books.
先人の設計に学ぶ
•GoF のパターンは UI 開発に使え
るものが多い
•GoF patterns are good for rich
user interface code design.
7. 迷ったら、シンプル
な仕組みを好む
if in doubt,
prefer simpler solution.
迷ったら、シンプルな
仕組みを好む
•複数の解法やライブラリなどで
迷ったら、シンプルな方を選ぶ
•If there are two or more ways
of solving problems, prefer
simpler one.
迷ったら、シンプルな
仕組みを好む
•jQuery, そして QUnit もそう
•Simpler solution may survive.
jQuery and QUnit have quality
and beauty of simplicity.
8. ソフトウェアの
梃子(てこ)の
効果を生かす
Use software leverage to
your advantage.
ソフトウェアの梃子(てこ)
の力を生かす
•なるべく車輪の再発明はしない(車
輪の再開発/実装はしてもいい)
•Don t reinvent the wheels. (But
re-implement them sometimes)
•UNIX 文化を尊重し、CUI を使
う。プレーンテキスト、スクリプ
ト、パイプ/フィルタを使いこなす
•Prefer CUI. Respect UNIX
culture. Use the power of plain
text format, scripting, pipes
and filters.
9. ブラウザを
使わなくても
テストできるようにする
Seek for the way of testing
outside the browser.
ブラウザを使わなくても
テストできるようにする
•env-js や xmlw3cdom.js は、ブ
ラウザや DOM のふりをする
•Try to use fake-browser-like
libraries. See env-js and
xmlw3cdom.js
QUnit-TAP というもの
を作りました
•QUnit-TAP (my product)
produces TAP output from
QUnit test code.
•http://github.com/twada/qunit-tap
10. 徹底的に
自動化する
Automate mercilessly.
徹底的に自動化する
•継続的インテグレーション : 自動
テストは定期的に実行させる
•Continuous Integration : Run
automated tests periodically
徹底的に自動化する
•hudson かわいいよ hudson
•hudson! hudson!
11. 未だフロンティア
である
Still in frontier.
未だフロンティアである
•JavaScript のテストの決定解は
いまだ無い
•Still no definitive solutions for
JavaScript testing.
未だフロンティアである
•JavaScript テストの未来を作る
のは、あなたかもしれない
•YOU may be the one. Create
the future of JavaScript
testing.
ご清聴
ありがとう
ございました
thank you very much.
延長戦
Extra time.
デモ : DEMO
•Spidermonkey + QUnit +
QUnit-TAP + Growl
•http://github.com/twada/qunit-tap
デモ : DEMO
•Spidermonkey + QUnit +
QUnit-TAP + xmlw3cdom.js
•http://github.com/twada/qunit-tap

More Related Content

10+1 Things you should know about JavaScript testing