フロントエンドに秩序を取り戻す方法のこの辺で自分の発表資料が引用されてたので返信してみる。
E2Eテストから導入することに関しては正常系のシナリオのみのテストを書くことを想定しています。E2Eでレグレッションテストはおすすめしません #nodefestB // フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9あとは、「テストを書くためのコード修正に周囲の理解が得られるか？」も基準になります。理解が得られるのであればUnitTestからの方が難易度は低いです #nodefestB // フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9E2Eテストは「既存のコードを修正しなくても割となんとかなる」、「正常系はリファクタ後もそのまま使える」って利点があるのでその前提の場合オススメします #nodefestB // フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9あと依存関係解決にはこれ使えると思う // フロントエンドに秩序を取り戻す方法 // Speaker Deck https://t.co/Whzvrpvzhu #nodefestB // フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9browserifyは各種plugin、transformで変換かけるフックが多いからそれはそれでありですが、既存コードへの修正も結構必要なので #nodefestB // フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9WebDriverもいいですが、Protractorも割と普通にいいので結構おすすめです（非Angularでも） #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9Testiumは簡単に使う分には問題ないですが、大規模な構成にはおすすめしません（コードカバレッジ取るのが面倒だったり、コード増えると遅くなったり） #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9Protractorはplugin系も豊富なので、事前にコード改変する系が差し込みやすいのも利点。個人的にはProtractor押しです #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9E2Eテストの問題点として「バグった時の原因究明が難しい」というのがあります。なので、E2Eテストは「落ちたら致命的なテストだけ」を書くのをおすすめします #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9なので、「最初にざっくり正常系のテストをE2Eでカバー」->「ロジックそのままでコード分割」->「UnitTestで分割されたコードの結合を保証」-> // #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9->「分割されたコード毎のUnitTest」->「リファクタしつつ改善」がおすすめですが、実際は面倒なので適当に飛ばすと思います＼(^o^)／ // #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9「機能追加を行わない既存コードの修正がどのくらい可能か？」、「コードの複雑さがどの程度か？」、「メンバーがどのくらいテストをかけるか？」みたいな部分が判断基準になります // #nodefestB フロントエンドに秩序を取り戻す方法 https://t.co/Whzvrpvzhu
— 尊厳 (@kyo_ago) 2015, 11月 9なんか足そうかとおもったんですが、割りといろいろはいってたのでとりあえずまとめました。