Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
KubernetesとGaugeを活用したTDD開発事例
Search
takayuki-hayashi
September 08, 2018
0
840
KubernetesとGaugeを活用したTDD開発事例
XP祭り2018の発表資料です。
発表した時の資料より文字を多くしてます。
takayuki-hayashi
September 08, 2018
Tweet
Share
More Decks by takayuki-hayashi
See All by takayuki-hayashi
E2Eの過去・現在・未来 そしてE2Eにおいて重要なこと
takayukihayashi
1
440
いかにしてテスト文化を醸成させたか.pdf
takayukihayashi
3
1.4k
リーダー、マネージャーが存在しない開発組織のつくり方
takayukihayashi
0
28k
AngularDartでDart入門
takayukihayashi
1
820
E2Eテスト駆動開発実践記_-_Web用.pdf
takayukihayashi
2
3.3k
FlutterとAngularDartを DIとClean Architectureで いい感じにする
takayukihayashi
3
2.1k
Gaugeによるe2eテスト
takayukihayashi
5
28k
Dartエコシステムの紹介
takayukihayashi
2
570
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Docker and Python
trallard
40
3.1k
Faster Mobile Websites
deanohume
305
30k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Building Adaptive Systems
keathley
38
2.3k
Become a Pro
speakerdeck
PRO
25
5k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Transcript
KubernetesとGaugeを活用し たTDD開発事例 〜 E2Eのお話 〜
自己紹介 • 林 尚之(はやし たかゆき) • Agile(XP)、TDD、DDDとかが好き ◦ 最近はDart(Web)、Kotlin(Server Side)を書く事が多い。clojureも勉強始めました
• 株式会社ユーザベース ◦ SPEEDA日本事業 CTO • twitter:@t_hyssh
E2E(受け入れ)テスト書いてますか?
E2Eテストって難しいですよね・・・
E2Eテストの実践を難しくする要因 • E2Eテスト環境の整備 • E2Eテストの記述コスト • 実行時間 • 再現性 •
CI/CDへの組み込み、統合 • etc...
これらの要因といかに戦うか
そしてE2Eを書く費用対効果をいかに 上げられるか
そのあたりがE2Eも含めたTDDを実践し 続ける上で重要な部分かなと思います
今日は弊社のSPEEDAというプロダク ト開発にてそれらの部分にどう取り組 んでいるのかという事を共有出来たら と思っています
アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
最初に伝えておくと
今から話をする内容で特に目新しい 事は何もないですw
偉大な先人達が技術書などで言って いる事をただやってるだけです
守破離の守ですね
SPEEDAの開発サイクル 着手するストーリー を決める E2Eテストを書く ユニットテストを書く ユニットテストを通す リファクタリング E2Eテストを通す
ストーリーに手をつける際に一番最初 にやる事はE2Eテストを書く事
「フィーチャを実装するときには、受け 入れテストを書くところから始める」 『実践テスト駆動開発』 Steve Freeman・Nat Pryce, P8
SPEEDAの開発サイクル(補足) • ストーリーに着手したら最初にやることはE2Eテストを書く事 ◦ E2Eを最初に書くことによって仕様の理解速度の向上、仕様の漏れの把握を迅速に行える • E2Eテストはテストエンジニア、ドメインエキスパート、プログラマーなどがペアプ ロをしながら書く • ストーリーの仕様を満たす記述が重要
◦ 画面を含むE2Eの場合、xpath等は最初は適当でOK • 最後にE2Eをパスさせる段階で細かい修正は入る ◦ xpathとか文言とか • E2EをパスさせないとストーリーをDoneにはしない • E2Eテストを書く以外の作業も基本的に全てペアプロ
E2Eをどういう単位で書いているか Service A Service B Service C BFF Front End
サービス毎にE2E作成 他サービスとの連携部分はMock化 サービス単体のE2Eは GETであればJSONを アサーション、POSTの 場合はDB、KVSのア サーション Front EndのE2Eがシステムとして の振る舞い(仕様) ユーザーが直接操作する Front EndのE2Eで関連する全てのサー ビスを連携させる サービス毎にE2E作成 他サービスとの連携部分はMock化
全体E2Eと個別E2Eを分けている理由 • 各サービスはここに挙げたサービス群以外から呼ばれる可能性がある • 他の機能の拡張のために修正する場合にそのサービスの仕様、E2Eがあるの が望ましい • サービスの独立進化を促進させるためにも個別のE2Eは必要
結果的に自然とこうなります Front Endの E2E 各サービスのE2E 単体テスト
デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 (バイナリ) の作成 Dockerイメージ の作成
& Push 個別E2E環境に デプロイ サービス単体の E2Eテスト実行 フルE2E環境に デプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ プロダクション環境 (Green)にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック(手動)
アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
SPEEDA開発におけるE2Eテストの定義
SPEEDA開発におけるE2Eテストの定義 E2Eテストとは 自動テストとして実行可能なドキュメント(仕様)
なのでドキュメント(仕様)を書く上での 表現力を重要視してます
そういった理由で 「Gauge」 を使ってE2Eを書いてます
Gaugeの特徴 • https://getgauge.io/ • ThoughtWorksが開発(OSS GPL3.0) • Markdown形式で記述可能 • Markdownのドキュメント(spec)にはプログラムのソースが一切介在しない
• リッチなレポートを出力可能 • 様々な言語でテストを記述することが可能(Java、C#、Ruby、Python) ◦ SPEEDAの開発ではKotlinで記述 • IDE機能が強力 • 並列実行のサポート
Markdownでの記述
Kotlin側の記述
IDEのサポート(サジェスト)
IDEのサポート(エラー表示)
アウトプット
Gaugeをどう使ってるか • WebはSelenideを仕様 • DBのアサーションはDBUnit • KVSに関してはKeyに対するValueをそのまま返すエンドポイントをサービスに 定義してその値を取得してチェック ◦ Production環境ではそのエンドポイントは無効化
Gaugeを使ってみた感想
Gaugeを使ってみた感想 • やっぱりMarkdown形式で書けるのは大きい • アサーションの方法とかは使う側が決めれるので押し付け感はない • 0.8くらい(?)から使ってたので情報少なくて最初は大変だった
課題
GaugeというよりE2Eの課題
「仕様を書く」という意識を高めないと 良いE2Eにはならない
例えば
良い例
悪い例 正しい理由、その仕様が書かれていない。 コメントも無い 「正しく」って???
こういった点を意識するには結構時間 がかかる
HTMLのレポートをあまり活用出来て ない・・・
アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例
E2Eテストを継続的に実践していく上 で運用コストは無視出来ない問題
Kubernetes
Kubernetes • Dockerに代表されるコンテナのオーケストレーションシステム ◦ 現時点ではもはやデファクトスタンダード • ローカル環境に構築したい場合はminikube ◦ それなりにメモリ必要です
minikubeを使う理由 • minikubeを使うことでStaging、Production環境と同じ環境(kubernetes)になる ので実行環境の一貫性を保てる • デプロイするアプリケーションが使用するストレージ(RDB、KVS、ES等)も全てコ ンテナ化する事で再現性を向上させる事が可能 • マイクロサービス化しているのでE2Eをローカルで実行させるためには複数の サーバーを起動させる必要がある
◦ Staging、Productionと同じデプロイ方法を使える
デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 (バイナリ) の作成 Dockerイメージ の作成
& Push 個別E2E環境に デプロイ サービス単体の E2Eテスト実行 フルE2E環境に デプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ プロダクション環境 (Green)にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック(手動)
デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 (バイナリ) の作成 Dockerイメージ の作成
& Push k8s上の個別E2E環境 にデプロイ サービス単体の E2Eテスト実行 k8s上のフルE2E環 境にデプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ k8s上のプロダクション環 境(Green)にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック(手動) ローカルの開発環境で単体テストをパスさせ、現在のストーリーに 対応するE2Eテストをminikubeを活用しつつパスさせる
フルk8s化する前は各E2E環境の整 備だったりに結構コストがかかってい ましたが現在はそれに時間を取られ ることはほとんどなくなりました
E2Eテストの実践を難しくする要因 • E2Eテスト環境の整備 • E2Eテストの記述コスト • 実行時間 • 再現性 •
CI/CDへの組み込み、統合 • etc... k8sで効率化 Gaugeで効率化 k8sで複数namespace切って実行するとかなり時間短縮に なるはず(まだ出来てないです) k8sとminikube、Dockerで再現性Up k8sで効率化
k8sとは関係ないですが • CI/CDはJenkinsを仕様 ◦ pipelineを全てgroovyスクリプト化 ◦ 現在はbuildkiteを試している所 • コンパイル、単体テストの実行、jarとかjsの成果物生成は全てDockerコンテナ で行い再現性を高めてます
• 「trunkベース開発」で行っているので基本的にブランチは存在しない ◦ https://www.infoq.com/jp/news/2018/05/trunk-based-development • マニュアルテストだと何日もかかるテストが毎日何回も実行されてます ◦ 実行すればするほど費用対効果は上がる
10年前とかに比べてE2Eテストを実施 するコストはかなり下がってきている
今や「ユニットテストは書くのが普通だ よね」となったように
近い将来「E2Eテストは書くのが普通だ よね」となるんじゃないかなと思います (願望)
JaSTT’18 TokyoでGoogleのJohn Miccoが言ってました
曰く 「Googleでは全て(UI含む)のテストを 自動化している」
かっこいい!
そこを目指して日々頑張っていこうと 思います
ご清聴ありがとうございました