サイボウズエンジニアのブログ2014-05-12kintoneのJSユニットテスト最新事情JavaScriptこんにちは。最近はJavaScriptのテストツールが著しく進歩し、日々新しいツールが登場しています。kintoneの開発もこれらのツールによって支えられています。kintone開発チームでは、昨年末頃からテスト環境の改善に取り組み、モダンなツールセットに乗り換えました。今回は、現在のkintoneのJSユニットテスト環境について紹介します。kintoneとJSユニットテスト数年前からユニットテストと自動化の仕組みはあったのですが、ごく一部のユーティリティ関数に書かれているのみで、普段の開発には活用されていませんでした。ここ1,2年ほどでテストスケルトンを生成するジェネレータスクリプトを作るテストの書き方をまとめたドキュメントを用意するMTGで「ユニットテストを書かなくていいのは小学生まで」などと煽るコードレビュー時にテストをお願いするといった活動をおこない、かなりテストが浸透しました。テストの仕組みがあまり使い勝手の良いものではなく、なかなか気軽にテストが書けないという問題がありました。使ってテストを書き、PhantomJSでテストを走らせていました。以下のような感じです。Libraryのリポジトリで確認することができます。Testemといったモダンなテストツールが普及するにつれて、徐々に不満が溜まっていきました。テストを書き始めるのに必要なスケルトンコードが多いJsUnitスタイルではなくBDDスタイルでテストを書きたいレポーターが選択できないPhantomJS以外のブラウザでテストできない自動監視によるTDDができないこれらの不満点をまとめて解消するため、新しいツールセットに乗り換えることを決めました。現在の仕組み赤い枠で囲まれているのが、kintoneで利用しているツール。Sinon.JSでテストを書き、Karmaで実行・レポーティングという構成になっています。テスト実行タスクはGruntでまとめています。基本的なテスティングフレームワークは、メンバーの好みとブラウザサポート状況等から選択しました。Libraryにもあったのですが、モダンなツールを使ったほうが簡潔に書けるため、まとめて乗り換えることにしました。一方で、テストランナーの選択はなかなかうまくいきませんでした。ロードするという事情があり、最初はTestemでテストを動かそうとしましたが、テストが実行されないwatchでCPU使用率が100%になるなどの問題が発生したため断念しました。その後Karmaを試してみたところ、安定して動作したため、めでたく乗り換えの目処が立ちました。乗り換えの効果ユニットテストのツールセットを乗り換えた結果、以下のような効果が得られました。約1分かかっていたのが約10秒に。柔軟なレポーターTDD時はspec形式、CI時はJUnit形式など。(後述)以前の不満点はほぼすべて解消され、高速化やカバレッジ測定などもできるようになりました!CIとの連携KarmaはCIジョブ向けのレポートファイルを出力することができます。karma-junit-reporterを使うとJenkinsのジョブにテスト結果のグラフを表示することができます。Jenkins上でテスト数の推移が一目でわかる!karma-coverageプラグインを使うと、さまざまな形式でカバレッジレポートを出力できます。cobertura形式で出力すると、Jenkins上でカバレッジが確認できます。Pluginを組み合わせることで、基準値よりも複雑なコードに警告を出すことができます。警告が増えたらビルドが不安定になりますこのように、CIと連携して各指標をグラフ化することで、コードの状態を知ることができるようになりました。発生した問題と回避策さて、新しいツールセットに乗り換えて良いこと尽くめだったかというと決してそうではなく、実際に運用するといくつも問題が発生しました。いくつかの実際に起きた問題とその回避策を紹介します。DOMが汚れて他のテストが失敗するこれまではテストごとにhtmlファイルが独立していたため、ひとつのテストが他のテストに影響を与えることはありませんでした。Karmaのようなテストランナーを使うと、複数のテストが同じページ上にロードされて実行されることになり、他のテストを失敗させる「行儀の悪い」テストが存在することが分かりました。行儀の悪いテストを分類すると、次のようになりました。個別に修正しつつ、全体としては以下のような対策をしました。afterEachでbody下に要素が追加されていたらエラーにするbeforeEachでグローバル変数をstub化するテスト用の状態をリセットするメソッドを追加するTDDでひとつのファイルを変更すると全部のテストが走ってしまうTDDでコードを書いているときは特定のクラスのテストだけ走ってほしいのですが、ひとつのファイルを変更するとすべてのテストが再実行されてしまうという問題がありました。テストに時間がかかりリズムが悪くなってしまうので、grunt-karmaの設定で読み込むファイルを指定できるようにしました。hoge_spec.jsのように特定のファイルだけテスト対象にしてサクサクTDDができるようになりました。installを実行すると、書き換え後のバージョンのモジュールがインストールされないという現象に悩まされました。hooksのpost-checkoutで実行するようにしました。シェルスクリプトはこちらがベースになっています。teppeis/post-checkoutまとめ最近のkintoneのJSユニットテスト事情について紹介しました。フロントエンドJavaScriptのテストも、ツールの進歩によりずいぶんやりやすくなりましたね。近ごろではさらにpower-assertのような素晴らしいツールも登場しており、まだまだ探求が必要だと感じています。DAYでテストについて探求したことがきっかけになっています。08:00関連記事2019-04-24YakumoのAWS開発環境とデプロイパイプラインの紹介こんにちは、Yakumoチームの[@ueokande][@ueokande]です。Cafe」を開催しましたこんにちは!品質保証部の中園です。メンテナブルなE2Eテストを書こうこんにちは。大阪開発部の岡田(@y_okady)です。LINKサイボウズ・ラボサイボウズ株式会社プライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。