テストしていますか？
手動テストも含めれば基本的に何らかのテストはやるだろう
目視でざっと見るのもテストですし。
テストって本当に必要なの？
当然必要だが、自動テストが必要かは場合による。
テストとは自動テストだけではない。
手動テストもテストとしてカウントできる。
テスト自動化の功罪
- 手動テストに価値がある
- 必要以上に主導テストが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とグラフで連携さすのは悪手だと思う
テスト技術は重要なのか
- テストの技術だけあってもテストは出来ない
- 問題領域の知識は重要
