大江戸Ruby会議01 高速なテストサイクルを回すには

Notes de l'éditeur

1. \n
2. \n
3. \n
4. \n
5. \n
6. \n
7. テスト時間は早ければ早いにこしたことはない。全部のテスト通すの遅いとやらなくなりがち\n
8. 1テストと、全テスト実行・主に二つに分けられる\n
9. ソリューションはいくつかありますがこんなものがあります なんでこんなのがあるかというと巨大なフレームワーク rails とかは実行コスト高いから\n
10. rails などは初期化コストが高いため、そのコストを削ることで高速化\n
11. 初期化処理＝Railsでいうboot.rbの読み込み＝必須ライブラリ等の読み込み\n
12. prefetch-rspec は自分自身を立ち上げ直してる。実際にテスト実行後すぐにコードを書き直して実行することは少ない(すくなくとも数秒かかる)ので、その空き時間を利用\n
13. テストを実行して結果を知るフィードバックの高速化\n
14. 明示的に「テストを実行」しなくてもゼロコストで実行\n
15. \n
16. \n
17. \n
18. \n
19. autotest はイレギュラーなことをやろうと思うとソース読んだりで面倒。watchr はまんま ruby でなんでもできる。この辺は好き嫌い。\n
20. \n
21. \n
22. クックパッドの事例\n
23. \n
24. テスト16分が遅いかどうか感じるのは日とそれぞれかも知れませんが\n
25. Cookpad ではどんどんエンジニアが増えていき、書かれてない箇所のコードはspecを追加して云ってるのでテストの実行時間は右肩上がり（ここも見直す必要があるかも知れないけど、テストが遅くなるから必要なspecを書かなくなるのは全く持って良くない)\n
26. ちなみにCIが通ってないともちろんデプロイ自体できない仕組みになってるので、他チームに大きく迷惑が\n
27. ちなみにCIが通ってないともちろんデプロイ自体できない仕組みになってるので、他チームに大きく迷惑が\n
28. \n
29. \n
30. るびーえんたーぷらいずえでぃしょん\n
31. \n
32. \n
33. \n
34. \n
35. メモリたくさん食べるけど…\n
36. 続いて…\n
37. \n
38. \n
39. \n
40. gcc なんかは結構昔からできたけど、LL のテストにも使えるなんて全然考えても居なかった\n最近のマシンって複数コアだったりスレッド実行できたりするよね\n
41. ただ並列実行時にも問題はあるはある\n
42. \n
43. \n
44. \n
45. \n
46. \n
47. \n
48. ならリモートにマシン用意して実行させれば良くない？\n
49. \n
50. \n
51. \n
52. メモリも減ってるのは、ローカルではリモートにタスク投げて結果を受け取るだけだから\n
53. \n
54. \n
55. \n
56. \n
57. \n
58. \n
59. \n