CIとTest Sizesの話 - asterisc

はじめに 前回 akito0107.hatenablog.com どちらかというとこっちが本編。 前回の記事ではTest Sizesについて紹介したが、今回の記事はその分類が実際の開発にどう役に立っているのかをまとめたいと思う。もちろん用語の統一も大きな意味を持つが、それ以外のことを書いていきたい。 具体的には、CIでテストのパイプラインを組む時にこの分類どおりに組んでいくと綺麗に整理でき、CI全体のスループット向上にも効果がでているという話だ。今回の話は僕たちのチームに特化した内容になるが、1) Test SizesごとにTestの起動コマンドを分ける、 2) Smallから順に実行していき、落ちるべきテストはできるだけ早期に落とす、というポイントはどこにでも使えるものだと思う。 コンテナ技術とテスト 僕たちはローカルの開発環境だけではなく、本番環境やCI環境でコンテナ技術（主にDock

[Kesin]

small/medium/largeのテストにそれぞれ分ける方法をテストフレームワークで提供して欲しいなあ。命名規則である程度頑張れるけども

[SWIMATH2]

レイヤーごとにテスト分割してたけどサイズ分割も良いかもなあ/lintとかはテストかどうかも怪しいし、うちでは一番最初に実行してそもそもビルドすら始めない（失敗する場合は数秒で終わる）ようにしてる

[f99aq]

"Small / Medium / Largeのそれぞれテストを別々のコマンドで分けて起動できるようにしておき、 Small は docker build の際に、 Medium は docker-compose で、 Large 以降はテスト環境に実際にデプロイしてから、とテストの実行のフェイズを

[teppeis]

ConcourseCI事例珍しい / test sizeを活用してビルドパイプラインを最適化高速化

[efcl]

test sizeでCIのpipelineを分ける話

[Dai_Kamijo]

Test Sizesの導入によるビルドパイプラインの最適化の話。コンテナ時代の CI のスループット阻害要因を Test Sizes 導入で改善しています。 / “CIとTest Sizesの話 - asterisc” — Takuto Wada (@t_wada) August 30, 2018 from Twitter https://twitter.com/D

[dkkoma]

とてもよさそう

[bufferings]

良いなー

[estragon]

「Small のテストはdocker buildと同じタイミングで、 Medium のテストは docker-compose でというようにきれいに整理できるため、今後はこの形でCIを整備していきたい」

[t-wada]

Test Sizesの導入によるビルドパイプラインの最適化の話。コンテナ時代の CI のスループット阻害要因を Test Sizes 導入で改善しています。

[murashit]

前回の記事で疑問に思ってたところが腑落ちした、なるほど

[t-murachi]

CI/CDの都合でテストの分類を定義するという考え方。とても理にかなっていると思う。