Tokyo#2」に参加してきました。当日は1回目の反省をふまえて以下の仕様について実施することとなっていました。JapanのHayatoさんがSpecを書いているので、テストがマージされやすいんじゃないか?!という不純な動機と、仕様が難しいので参加者が少ないかな?という妄想からでした(ただ実際は一番人気でした!)。そもそもこの活動は何なのか?というと、みんなでHTML5やCSS、API仕様のテストケースを書こうというミートアップですと書いてある通りです。私たちWebに関わるデベロッパーであれば必ず利用するHTMLやCSS、ブラウザによって実装がマチマチでとか、IEがぁーとか言ってますよね。なるのか?まずHTMLとかCSSはW3Cの仕様があってそれを各ブラウザベンダが実装するわけです(もちろん先に実装されているケースもあります)。結果としてどのように見えるのか?という部分に関して言うと、特にこうなるべきという具体的な結果が書いてある訳ではありません。なると各ベンダは自分の実装は正しいと思ってリリースするのですが、それぞれバラバラだったという結果が起きるのです。そのため、W3Cではテストの充実に力を入れているのですが、現時点ではリソース不足であったり、そもそもスペックの理解不足という自体が起こります。W3Cのスペックを読んだことがあると何となく想像できるかな、と思います。Forwardという公式イベントや、今回のようなコミュニティ主導のミートアップでテストコードを充実させようという機会が増えてきています。Forwardのドキュメントを見れば、今時のWebデベロッパーであれば問題なく環境を構築することができます。必要なのに漏れていた(これについては今回のミートアップでPRが出されてマージされたはずです)り、ちょっと面倒なのですがまぁ問題ないでしょう。そのうちVagrantファイルでも作ろうかなーと思っています。ここまでは事前の準備としてやっておきました。当日やったことW3Cのスペックを見ましょう。Itoさんから仕様の説明を受けて進めるという流れだったのですが、それにしても仕様がむずい。新しいテストケースはちょっと置いておき、既存のテストを流してみることにしました。これはすぐ取り込まれました。しているテストについて、スペシャリストの方に確認して修正方針を聞いたりして、テストを黙々と書いていきます。1日作業でしたが、2つのテスト失敗を修正してタイムアップ。DOMはtestharness.jsでDOMのテストをする段階でした。記法になっていて、キモい!という話をしたら、開発者がmozilla系の方でfire方面ではそういう記述になっているという話を(FireFoxのcontributorの方から)伺うことができました。これもミートアップでこその体験です。モダンなテストの書き方という意味では、サーバサイドスクリプトとか今時のJavaScriptのテスティングフレームワークの方がイケてる感じにできますが、これも歴史的な背景(DOMの細かい評価をするのにtestharness.jsが最適であるという理由)ということです。今後についてはわからないけど、各ブラウザベンダなどがテストするときに利用しているということで変更(例えばJasmineに変えるとか)には高い壁があるのかもしれないです。最後にW3Cの活動に貢献する作業は今後も続けて行きたいので、ミートアップなくてもテストコードを書き続けて行きたいとおもいました。metaデータの書き方とかちょっと特殊なところもあったので、新しくやる場合は既存のテストコードをいくつか参照して、書き方のテンプレート部分を把握した方が良いと思いました。氏が初来日ということで基調講演を聴く事ができました。2年間かかって作ったという最高傑作テストケースを見てスペックのテストとは!を感じれたのも良かった。フォントもインストールしました。さん(ノベルティまでいただき感謝!)、スポンサー各社様の協力でとても楽しいイベント(部活)でした。