BLOG開発関係のメモこの広告は、90日以上更新していないブログに表示しています。TDD経緯Backbone.jsでTDD書く時に、Model/CollectionはServerSideのようなイメージで書けるのだが、Viewのテストがfrontend特有の事があり、結構、悩ましい。ここでは、Backbone.Viewを中心に、テストで悩ましい所をどう解決していくか、試行錯誤している所等書く。※どちらかというと、初めにどう書いて行くか?のTDD寄りの話。ちなみに、環境は、BackboneMarionette.jsTestmochachaisinon.jsを使ってる。初めに、Viewのテストの基本形から。});});こんな感じで書いて行く。1初期化view毎回newするの面倒なのでbeforeで。(大体、皆一緒)(initializeの中身をテストするなら、ちょっと調整が必要)場合によってはrender入れてもいいかと。(Marionetteとか。面倒くさければ、editorのsnippetsに登録すると良い。色んなお悩みを書いて行く。悩み1jsだけでなく、html/DOM迄考えなくては行けない事サーバーサイドのテストサーバーサイドのTDDは、以下のたった2つのソースだけを行き来して書けば良かった。ターゲットソーステストソースとても、シンプルだし、何よりTDDに集中できる。BacboneもModelやCollectionは、同じイメージで書けるのだがViewは少し違う。Backbone.ViewのテストBackboneのViewのテストは、ターゲットとテストソース以外に、ターゲットのhtmlや場合に寄ってはテスト用のhtml等のファイルも行き来が必要になったりする。これらも含めてTDDしようとすると、以下の問題に直面する。開発フローの中でのTDDの必然性が薄れてテスト習慣がつかなくなる。問題2:htmlがデザイン変更等から多くのテスト変更を伴う問題htmlはデザイン等頻繁に変わる事あるので、テスト書いてもDOM操作を中心に頻繁に調整が必要になる。(expext($(‘#aaa’).text()).toBe(‘aaa’)みたいなの一個ずつ直す必要あるし、test用のでかいtemplateとか準備してるとマジ地獄。実装直すなら、テストも直すのは当然で正しいのだが、量が多いのが問題。単純に対象ソースとテストソース見比べれば良かったサーバーサイドのTDDと比べて、frontendのTDDはあっちこっちファイル見比べてTDD以外の考慮が多いので、TDDしようとする集中力とやる気を削ぐ。この集中できないのが一番問題。jsのTDDに集中するには。TDD続けるには、とにかく、作業ファイルをターゲットソースと、テストソースの2つだけにするのが良いと思う。template出来るだけ使わない(修正が面倒)最悪、使っても、1,2行の断片程度でターゲットとなるViewも整理する元のViewは、el内だけを扱う。(el以外への変更はtriggerして、別Viewに)View内でelを指定しない。(これで、テスト用template要らなくなるはず)(Marionetteに沿って書くとRegion使うので、そうなってるはず。書かないなら、別のレベルのテストで確認が必要。DOM/htmlを完全にスルーするという話ではない。TDDみたいに、始めてTest書く時にはDOM意識しなくていいのでは?という話。何書いていいかわからなくなる。注意:ただのimageですと書けたらいいのに。イベント以外にも、困った事に素直に検証書けない所がいっぱいある何があるか?整理するためViewに書いてる事を整理するとViewに書いてる主要な事Viewに大体こんな事書いているんじゃない?インスタンス変数の初期化/変更メソッド呼び出しイベントbind/triggerサーバー通信DOM操作(アニメ)window.confirm()等local変数(model等)のCRUDこの中で、instance変数の変更はサーバーサイドと同じ。メソッド呼び出しも、spy/stubs使えそうなのは、すぐimage湧く通り。"confirm").returns(false);でいい。DOM操作は、jQueryでチェックし直せば良い(それぞれのTestFW上でjQuery操作補助するライブラリあるので、それ使うと楽)この辺りは普通にイメージの湧く通り。問題は、それ以外の残った所。残った要素イベントサーバー通信アニメlocal変数(model等)これら、全部、色んな事情で結局テストダブルが必要。問題有ったときの原因の切り分けも面倒くさい。itexpect(this.stub.called).to.be.true;アニメ何秒か待っても書けるが、テスト時間かかるsinonのfakeTimer使うとすぐ終わる。it()this.view.saveTask();expect(this.mock.verify()).to.be.true;Viewのテストで思った事これで、一通り、書けるハズ(多分)しっかし、Backboneのテストはコストかかるなー。Backbone.View(特にmarionette)の関数=小粒になる最小単位のUTが効果的と思えない(あまり複雑なlogic無い。関数Aといえば命令Bする!はい終わり!みたいなので、bugが入り込む余地が少ない)sinon書くの結構大変。※100点とは思わないけど、一番参考になる。21:53Backbone.jsのテストの悩みとその解決Tweet広告を非表示にする関連記事2014-02-03Ractive.js入門これは、jsCafe18で話したSlideです。これから、「Ractiv...2014-01-23Backbone.jsとMarionette.jsで発表してきたBackboneとMarionetteの発表してきた。※この記事は社内勉強会向けの資料の下書きです。※これは、社内の勉強会の資料の下書きです。(2)はてなブログをはじめよう!lxyumaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。