最近Haskell
に入信した小飼です。全然わからなくて最高です。
さて、先日弊社公式サイトのアクセスログを見ていた所、angularjs 請負
という検索ワードでの流入がありました。 弊社では、この一年ですっかり主流となった観のある仮想DOMライブラリによるアプリケーション構築の他に、AngularJS
/Vue.js
などのMV*フレームワーク
によるアプリケーション構築も手掛けています。
※その際に得た知見は、このブログでも随時公開しています
AngularJSタグのポスト Vue.jsタグのポスト
現時点から新規でアプリケーションを構築するなら仮想DOMライブラリに乗っかっておくのが時流かも知れませんが、まだまだ世の中にはAngularJS
製アプリケーションも多くあるのではないでしょうか。 その中には「プロジェクト立ち上げ時には主流だったAngularJS
が、すっかり流行り廃りの波に飲まれてしまってメンテナンスがしづらくなってしまった…」というような事があるのかも知れません。 (もしそういった方がいればぜひ弊社にご連絡下さい)
今回は、そんなメンテナンスしづらくなっているAngularJS
アプリケーションを仮定して、継続的に開発を続けていくためにユニットテストを導入した際の一例をご紹介します。 想定しているのはこんな構成のアプリケーションです。
AngularJS
を用いたシングルページアプリケーション(SPA)
AngularJS
のモジュールシステムのみ使用している(!CommonJS)
テストコードはない
要件の追加に合わせて、1年以上随時機能拡張をしてきた
重複しているコードや、太りすぎたController
が随所にある
がんばり :muscle:
想定しているリファクタリング要件 まずどんな機能についてユニットテストを書きたいのか、という前提を書いておきます。 例えばこんな感じで、あるAPI
のエンドポイントに対して、Controller
が変わる毎にリクエストを送る機能があるとします。 (省略されている部分に$routeProvider
によるルーティングをしている記述があり、各ページ毎にController
がある、という設定です)
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 function sampleResourceWrapper ($resource ) { return $resource('/api/endpoint' , { someParam: '@someParam' , }); } function sampleController1 (sampleResourceWrapper ) { const s = new sampleResourceWrapper({ someParam: 'someOwnParam' }); s.someFixingParam1 = 'someFixingParam1' ; s.someFixingParam2 = 'someFixingParam2' ; s.someFixingParam3 = 'someFixingParam3' ; s.save().$promise .then((response)=> console .log(response)); } function sampleController2 (sampleResourceWrapper ) { const s = new sampleResourceWrapper({ someParam: 'someOwnParam' }); s.someFixingParam1 = 'someFixingParam1' ; s.someFixingParam2 = 'someFixingParam2' ; s.someFixingParam3 = 'someFixingParam3' ; s.save().$promise .then((response)=> console .log(response)); } angular.module('sampleApp' ).controller('sampleController1' , sampleController1); angular.module('sampleApp' ).controller('sampleController2' , sampleController2); angular.module('sampleApp' ).factory('sampleResourceWrapper' , sampleResourceWrapper);
こんなコード書く人いる…?という感じになっていますが… 長い開発期間の間に、少しずつこういうコードが溜まっていったということにして下さい。
例えば最初はsampleController1
だけを実装していた、ある時期に追加のsampleController2
が作られた、その時に時間が無くてsampleController1
の実装をコピペした…(以下繰り返し) というようなケースは実際にあるのではないでしょうか。 しかも実開発環境では、この他に何十、何百というファイルがあるので、次に両方のコードにチェックインするまで問題が表面化しづらいように思います。 この調子でsampleController10
まで増えた後に、必須パラメータが追加されたとしたらどうなるのでしょうか。
恐ろしいですね。
ちなみに、私はこういうコードを見てしまったらその時に直してしまうようにしていますが、リファクタリングタスクとしてきっちり時間を取って改善していくようにしたほうがいいかも知れません。 (この辺はチームの性格とか構成にもよると思います)
テストで全体の挙動を保護 まず、テストを追加したい機能を含む一番大きな単位に対してテストを追加します。 今回想定しているアプリケーションでは、各ページ毎に設定されているController
が最大の単位ということになります。
ここはほとんどE2E
のテストを書くようなイメージで、最終的にこのページが責任を持たなければいけない機能に対してテストを書きます。 ただし、太りすぎたController
が随所にあるという想定ですので、全ての機能を担保するテストコードを書くのは現実的では無いと思います。 そこで、まずはユニットテストとして切り出したい機能のみに注目してテストを書きます。
テストが入っていない場合、各機能が密結合していて単機能だけのテストを書きづらいので、まずはこの機能は何をしなければならないのか
をこのページは何をしなければならないのか
の中に含めてしまう、というイメージです。
この時、チャチャッと直してしまいたい箇所が目につくと思いますが、グッと堪えます。 また、他にも事前の通信処理が必要だったり、サードパーティ製ライブラリ(アナリティクス系ツールとか)がリクエスト投げてたりしていて沢山のモックを作る必要が出てくるかも知れませんが、頑張ります。 (テストを書けば書くほど、新たに必要なモックは少なくなっていくので、その日を夢見て頑張ります)
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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 describe('Controllers: sampleController1' , ()=> { var scope, element, httpBackend; beforeEach(()=> module ('sampleApp' , 'httpBackendMock' , 'controllerTemplate1.html' )); beforeEach(()=> { inject(($rootScope)=> { scope = $rootScope.$new (); scope.$digest(); }); inject(($httpBackend)=> { httpBackend = $httpBackend; }); inject(($compile, $templateCache)=> { const template = $templateCache.get('controllerTemplate1.html' ); element = $compile(template)(scope); document .querySelector('body' ).appendChild(element); }); inject(($controller)=> { $controller('sampleController1' , { $element: element }); scope.$digest(); }); }); it('リクエストを投げている' , ()=> { httpBackend.expectPOST(/\/api\/endpoint/ ).respond({}); httpBackend.flush(); }); it('パラメータが渡っている' , ()=> { httpBackend.expectPOST(/\/api\/endpoint/ , { someParam: 'someOwnParam' , someFixingParam1: 'someFixingParam1' , someFixingParam2: 'someFixingParam2' , someFixingParam3: 'someFixingParam3' , }).respond({}); httpBackend.flush(); }); }); describe('Controllers: sampleController2' , ()=> { var scope, element, httpBackend; beforeEach(()=> module ('sampleApp' , 'httpBackendMock' , 'controllerTemplate2.html' )); beforeEach(()=> { inject(($rootScope)=> { scope = $rootScope.$new (); scope.$digest(); }); inject(($httpBackend)=> { httpBackend = $httpBackend; }); inject(($compile, $templateCache)=> { const template = $templateCache.get('controllerTemplate2.html' ); element = $compile(template)(scope); document .querySelector('body' ).appendChild(element); }); inject(($controller)=> { $controller('sampleController2' , { $element: element }); scope.$digest(); }); }); it('リクエストを投げている' , ()=> { httpBackend.expectPOST(/\/api\/endpoint/ ).respond({}); httpBackend.flush(); }); it('パラメータが渡っている' , ()=> { httpBackend.expectPOST(/\/api\/endpoint/ , { someParam: 'someOwnParam' , someFixingParam1: 'someFixingParam1' , someFixingParam2: 'someFixingParam2' , someFixingParam3: 'someFixingParam3' , }).respond({}); httpBackend.flush(); }); });
AngularJS unit testing
なんかで検索すると、whenPOST
で擬似レスポンスを設定する記事の方が多く見つかるかも知れません。expectPOST
にすることによって、1回1回のリクエストを、どんなパラメータで発行されたかがテストしやすいので、特に事情がなければexpectPOST
をオススメします (もちろん他のリクエストメソッドについても同様です)
この時、Controller
のテストが太りに太って大変な感じになるかも知れません。 これは一時的なことで、きちんとテストが整備されていくにつれて、Controller
のテストも軽くなっていく(本来の責務に応じたサイズになっていく)ので、耐えます。
ただし共通化できる処理(スコープ・コントローラ・コンポーネントの生成など)は極力共通化して少しでも楽をできるようにした方が良いかも知れません。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 describe('Controllers: sampleController1' , ()=> { var scope, element, httpBackend; beforeEach(()=> module ('sampleApp' , 'httpBackendMock' , 'testHelper' , 'controllerTemplate1.html' )); beforeEach(()=> { inject(( createScope, createElement, setController, $httpBackend )=> { scope = createScope(); element = createElement(); setController('sampleController1' , element); httpBackend = $httpBackend; }); }); });
切り分ける 前段で保護した範囲の機能を部品として切り出します。 今回は通信機能のみなので、Factory
として切り出すのが良さそうですが、View
に関わる部分でしたらElement Directives(Component)
として切り出すことになると思います。
1 2 3 4 5 6 7 8 9 10 11 12 13 function sampleResourceWrapper ($resource ) { const baseResource = $resource('/api/endpoint' , { someParam: '@someParam' }); return (someOwnParam)-> { const s = new baseResource({ someParam: someOwnParam }); s.someFixingParam1 = 'someFixingParam1' ; s.someFixingParam2 = 'someFixingParam2' ; s.someFixingParam3 = 'someFixingParam3' ; return s.save().$promise; }; }
切り出した部品を、元のController
の該当箇所に差し替えます。
1 2 3 4 5 6 7 8 9 function sampleController1 (sampleResourceWrapper ) { sampleResourceWrapper() .then((response)=> console .log(response)); } function sampleController2 (sampleResourceWrapper ) { sampleResourceWrapper() .then((response)=> console .log(response)); }
この時点でテストが失敗していたら、切り出した部品が仕様を満たしていないということなので、直します。 テストが通れば部品化の成功です!
テストを切り分ける 最初にController
のテストに書いたテストを、Factory
のテストとして切り出します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 describe('Factories: sampleResourceWrapper' , ()=> { var _sampleResourceWrapper, httpBackend; beforeEach(()=> module ('sampleApp' , 'httpBackendMock' )); beforeEach(()=> { inject(($httpBackend, sampleResourceWrapper)=> { httpBackend = $httpBackend; _sampleResourceWrapper = sampleResourceWrapper; }); }); it('パラメータが渡っている' , ()=> { _sampleResourceWrapper({ someParam: 'someOwnParam' }); httpBackend.expectPOST(/\/api\/endpoint/ , { someParam: 'someOwnParam' , someFixingParam1: 'someFixingParam1' , someFixingParam2: 'someFixingParam2' , someFixingParam3: 'someFixingParam3' , }).respond({}); httpBackend.flush(); }); });
ただし、この場合リクエストを投げること
そのものはController
の責務なので、Controller
のテストとして残しておきます。
1 2 3 4 5 6 7 8 9 10 11 describe('Controllers: sampleController1' , ()=> { var scope, element, httpBackend; beforeEach(()=> module ('sampleApp' , 'httpBackendMock' , 'testHelper' , 'controllerTemplate1.html' )); it('リクエストを投げている' , ()=> { httpBackend.expectPOST(/\/api\/endpoint/ ).respond({}); httpBackend.flush(); }); });
これでリファクタリング作業は完了です!
必須パラメータが追加された? 切り出したFactory
にちょっと追記するだけで良いので、楽勝ですね!
まとめ 長期間アプリケーションをメンテナンスしていく上で、重複した記述や非効率的な書き方が出てくるのは仕方がないと思っています。 コードレビューでフィルタする事ができれば理想的ですが、レビューのスコープ外のコードと重複していたりして、中々発見しづらいのが現実です。 また、時間の経過によって非効率的な書き方ということになってしまう書き方というのもあると思います。 (トレンドの変化が激しいJavaScript
界隈ではなおさらです)
ですので、書いた時点で完璧な書き方を目指すよりは、良くない書き方が紛れ込んだ時・見つけてしまった時に改善する仕組みを走らせられるかが大事なんじゃないかと思いました。
本当はDOMの操作を含む機能のテストにも触れるつもりだったのですが、ここまでで長くなりすぎて全く触れられませんでした… DOMにまつわるテストが整備されていくと、作りたいコンポーネントだけをテスト環境で描画して作っていくような、TDDっぽい手法で開発ができて最高なので、いずれ紹介したいと思います。
参考にした書籍やコンテンツ