Siestaのコツ: テストクラスの拡張
こんにちは、ゼノフィnakamuraです。
Siesta の素晴らしい点の1つはその拡張性です。利用者がカスタマイズ、オーバーライドできるように、コアから設計されています。いくつかのテストを作成すると、DRY 原則に従わない重複したコードを見つけることでしょう。そうしたら、その時点で組み込まれているSiesta テストクラスを拡張するべきです。自分のテストクラス内にテストでよく使うコードスニペットを入れられます。これは独自の抽象化でSiesta.Testクラスを拡張するガイドで詳しく説明されています。このブログ記事では便利なサニティチェックのコツを紹介します。
最近のバグレポート…
最近 Scheduler コンポーネント内で変なレンダリングの乱れが起こるというバグレポートがありました。具体的には、グリッドの実装で正確にレンダリングされなくなりました。我々は Ext JS の Grid クラスの元のレンダリングメカニズムをオーバーライドしていないので、とても不思議に思いました。長い時間をかけて、やっとその原因が分かりました。ある部分で Ext.suspendLayouts()
を呼び出したあとに、Ext.resumeLayouts()
を呼び出すのを忘れていたのです。このバグはランタイムエラーを起こすことなく、見た目が予想外のおかしなレンダリングをするだけなため、これを発見してデバッグするのは困難です。二度とこんなデバッグをしたくなかったので、Bryntum.Test
クラスの initialize
テンプレートメソッド(Siesta.Test
を拡張するもの)をオーバーライドすることにしました。このメソッドで各テストが完了する直前に発火される 'beforetestfinalize'
イベントリスナーを簡単に挿入できます。これがレイアウトが中断されてないことを確かめるなどの、各テストのサニティチェックをする素晴らしいフックを提供してくれます。レイアウトが中断されているコンポーネントを検出するには、Ext.ComponentQueryを利用します:
1 2 | // Use the power of Ext CQ Ext.ComponentQuery.query('{isLayoutSuspended()}') |
次のスニペットは5分で書きました。これを自分のテストクラスにコピペすれば、もうこのデバッグしにくい問題に直面せずにすみます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | Class('Bryntum.Test', { isa : Siesta.Test.ExtJS, methods : { initialize : function() { this.SUPERARG(arguments); this.on('beforetestfinalize', function() { var win = this.global; if (win.Ext) { var suspendedComponents = this.cq('{isLayoutSuspended()}'); // only report in case of failure if (suspendedComponents.length > 0) { this.diag('POST TEST SANITY CHECKS'); this.is(suspendedComponents.length, 0, 'No components found with layouts suspended'); this.fail('Suspended layouts detected for components', { annotation : Ext.Array.map(suspendedComponents, function(cmp) { return (cmp.id + '(' + cmp.xtype + ') ') }).join('\r\n') }); } if (win.Ext.AbstractComponent.layoutSuspendCount > 0) { this.is(win.Ext.AbstractComponent.layoutSuspendCount, 0, 'Layouts should not be suspended globally by accident'); } } }); } } }); |
他にこの方法で行われるサニティチェックは思いつきますか?教えてください!
Happy testing!