読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

JavaScriptテストの疑問、お答えします。 #frontrend

勉強会

テストしていますか?

手動テストも含めれば基本的に何らかのテストはやるだろう

目視でざっと見るのもテストですし。

テストって本当に必要なの?

当然必要だが、自動テストが必要かは場合による。

テストとは自動テストだけではない。

手動テストもテストとしてカウントできる。

テスト自動化の功罪

  • 手動テストに価値がある
  • 必要以上に主導テストがdisられていないか
  • 自動化は必要だが常に良いわけではない
  • 費用対効果の検討は必要

常に自動化がよいとは限らない(ただ、手動テストはあまり語ることはない)

あまり意味がある気がしないんだけど

割に合わないならやらないほうがいいが、改善は必要

テストを特別視しすぎ

  • 開発手法やフレームワークのように費用対効果の検討を
  • 仕事でやるなら予測が必要
  • 使ったことのない手法の費用対効果を予測するのは困難(やったことがないならやめましょうは当然の判断だと思われる)

  • 最初は捨てる前提で簡単な部分から

  • 自動テストは個人でも簡単に実践できる
  • 費用、効果は開発者の技術力、経験によって違う

  • 改善していけばコストは低くなる

  • ただし、テスト技術はテストしないと身につかない

どこまでやればいいの

  • できるところまで(ざっくりとした解答だが)
  • テストは個人のスキルに大きく依存する
  • 見極めができないならできるところまで

UIのテストはやらないっていうけどJSはほとんどUIだよね

  • 不安がやるならUIもやるべき
  • 不安をどう乗りこなすか
  • テストとは不安と向き合うための方法である

  • UIはやらない=UIのテストは費用対効果的に難しい

  • 最近はUIのテストもコストが低くなりつつある

今テストを書いていないところにテストを書くには

  • テストを考慮していないコードに対してユニットテストを書くのは難易度が高い
  • E2Eテストは比較的ターゲットコードの品質に依存しない

エンドツーエンドとは 【 end to end 】 【 E2E 】 - 意味/解説/説明/定義 : IT用語辞典

  • テストの文化が根付いていない環境でテストをする困難もある
  • テストが難しい部分の修正にテストがいる問題

JSのテストは大変

  • サーバサイドも昔は大変だった
  • UIがなくなってAPIベースになった部分も大きい

テストの目的

  • なぜテストをするのか
  • 目的がなければやってはいけない(テストがあったほうがいいですよねじゃ解答にならないが、とりあえずこんなもんかなっていう)
  • 見栄、不安の解消

自分の不安の解消

  • 非常に健全な理由
  • 安心できるまでやる
  • 自己満足にならないように

他人の不安の解消

  • 繰り返していることの省力化
  • 技術ではなく信頼感
  • 便利屋にならないように
  • ただし、技術がわからない人には見えづらい

自動テストの自動化

  • 今やっている手動テストを自動化する
  • 手順を省略したい
  • 効果を周囲に説明しやすい
  • はじめよう

複数環境懸賞

  • さらっと流すだけでも安心感高い

リグレっしょんテスト

  • バグが出た時だけテストを書く
  • 難易度は高い
  • 周囲の理解は得やすい
  • テスト文化の呼び水
  • 場当たり的になりがち

ドキュメント代わり

  • 主なAPIだけ
  • 他のテストとは分離を

知識の共有

  • チームに対する情報共有
  • ペアプロ的にやる(片方さぼっているならテストをやっていたらそれぽくみえる)
  • 知識の共有が進みやすい

設計

  • TDD的な意味で
  • 最初は目指さないほうがいい
  • なれるまでは気にしない

目的に注力したテスト

  • テストの目的は豊富
  • 目的にあった内容
  • みんなテストの認識が違いすぎる
  • やればやるほどよいってわけではない
  • なぜなんのためにテストをするのか
  • 他人の不安の解消のためにテストを書いても意味がない

一般的じゃない きれいじゃない

  • 目的を達成できれば勝ち

テストを書く文化

  • 技術的な問題より文化的な問題のほうが対応が難しい
  • すでに文化があるなら導入は難しくない
  • テスト以外にも方法がある
  • 不安の可視化
  • 不安がわからないなら周りに聞く(そもそも不安がないならテストしなくてよいのでは)
  • 本来の意味での「杞憂」を解消するためにテストをする必要はない

テスト、事始め

  • 最初からユニットテストはおすすめしない
  • ユニットテストは自動化しやすいけど難易度がたかい
  • Assertionからはじめる
  • assertでよく止まる箇所は複雑な可能性が高い
  • 切り出してテストする
  • 出力が気になるならconsole.assertを殺す

どこからやっていいか分からない

  • テストを書く技術を伝えることは難しくない
  • どこが不安かを認識する技術を伝えることは非常に難しい(それだけで高い技術を求められる)
  • 一般的な不安点は切り出されている
  • 残るのはどこが不安かよくわからないビジネスロジック

無理だったら引き返してみる

  • 社内ハッカソンや勉強時間に業務コードを捨てる前提のテストを書いてみては

テスト書いたけどなんか違う

  • テストは銀の弾丸ではない
  • テストの費用対効果は悪いことがある
  • 足を引っ張っていると思ったらすてる
  • 部分的、基盤ぶぶんを捨てないように

そもそもの話

  • テストを書かなくていい環境はある意味ただしい
  • 複雑なところはフレームワークが隠蔽
  • フレームワークに乗っかるとテストの必要性、不安ポイントが分からない
  • 不安点を集中させてそこをテストでカバーする

実践

ツール

  • ユニットテストはMochaやJasmineが主流(QUnitもあり)
  • SinonJSはアレ
  • Promiseのテストパターン
  • PowerAssertの一般化
  • E2EテストはProtractorが強い
  • testiumにも期待
  • テストランナーはtestemでもいいけど規模が大きくなるならkarmaがおすすめ
  • Ismorphicな利点
  • モジュール分割してロジック分離
  • テストを別言語で書くかどうかは微妙(testだけcoffeeみたいなやりかた)

テストと数値

  • バグの発生曲線的な
  • 難しい問題(コードカバレッジを数値として扱うのは否定的)
  • 可視化するほどでかいのをやったことない

テストの振り返り

  • そのテストは本当に訳に立ったのか

コードカバレッジどうする

  • 誰の不安がどういうふうに改善されるかよくわからないから微妙。
  • 数字は簡単に増やすことは出来る
  • 単純に数値が増えることで偽の安心感を得てしまわないか
  • 今このタイミングでカバーしていない部分を把握したい、という目的ならアリ。
  • でもカバレッジを増やせば品質向上につながるわけではないからCIとグラフで連携さすのは悪手だと思う

テスト技術は重要なのか

  • テストの技術だけあってもテストは出来ない
  • 問題領域の知識は重要