JavaScriptテストの疑問、お答えします。shigemk2当面は技術的なことしか書かない2015-02-21JavaScriptテストの疑問、お答えします。#frontrend勉強会テストしていますか?手動テストも含めれば基本的に何らかのテストはやるだろう目視でざっと見るのもテストですし。テストって本当に必要なの?当然必要だが、自動テストが必要かは場合による。テストとは自動テストだけではない。手動テストもテストとしてカウントできる。不安がわからないなら周りに聞く(そもそも不安がないならテストしなくてよいのでは)本来の意味での「杞憂」を解消するためにテストをする必要はないテスト、事始め最初からユニットテストはおすすめしないユニットテストは自動化しやすいけど難易度がたかいAssertionからはじめるassertでよく止まる箇所は複雑な可能性が高い切り出してテストする出力が気になるならconsole.assertを殺すどこからやっていいか分からないテストを書く技術を伝えることは難しくないどこが不安かを認識する技術を伝えることは非常に難しい(それだけで高い技術を求められる)一般的な不安点は切り出されている残るのはどこが不安かよくわからないビジネスロジック無理だったら引き返してみる社内ハッカソンや勉強時間に業務コードを捨てる前提のテストを書いてみてはテスト書いたけどなんか違うテストは銀の弾丸ではないテストの費用対効果は悪いことがある足を引っ張っていると思ったらすてる部分的、基盤ぶぶんを捨てないようにそもそもの話テストを書かなくていい環境はある意味ただしい複雑なところはフレームワークが隠蔽フレームワークに乗っかるとテストの必要性、不安ポイントが分からない不安点を集中させてそこをテストでカバーする実践ツールユニットテストはMochaやJasmineが主流(QUnitもあり)SinonJSはアレPromiseのテストパターンPowerAssertの一般化E2EテストはProtractorが強いtestiumにも期待テストランナーはtestemでもいいけど規模が大きくなるならkarmaがおすすめIsmorphicな利点モジュール分割してロジック分離テストを別言語で書くかどうかは微妙(testだけcoffeeみたいなやりかた)テストと数値バグの発生曲線的な難しい問題(コードカバレッジを数値として扱うのは否定的)可視化するほどでかいのをやったことないテストの振り返りそのテストは本当に訳に立ったのかコードカバレッジどうする誰の不安がどういうふうに改善されるかよくわからないから微妙。数字は簡単に増やすことは出来る単純に数値が増えることで偽の安心感を得てしまわないか今このタイミングでカバーしていない部分を把握したい、という目的ならアリ。17:18JavaScriptテストの疑問、お答えします。日)web系エンジニアの速記的備忘録。メモ書き故、中身については保証致しません。実在している団体等とは一切関係ありません。月別アーカイブブックマーク数はてなブログをはじめよう!shigemk2さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。