84.2K Views
June 14, 24
スライド概要
JJUG CCC 2024 Springでのスポンサーセッション「テストコードが根付くチームを立ち上げるために考えたいこと」の公開資料です。
シンプレクスは1997年の創業以来、メガバンクや大手総合証券を筆頭に、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきました。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域でもソリューションを展開しています。2019年3月にはAI企業のDeep Percept株式会社、2021年4月には総合コンサルティングファームのXspear Consulting株式会社がグループに加わり、創業時より付加価値の創造に取り組んできたシンプレクスとワンチームとなって、公的機関や金融機関、各業界をリードする企業のデジタルトランスフォーメーション(DX)の推進を支援しています。
JJUG CCC 2024 Spring テストコードが根付く チームを立ち上げるために 考えたいこと シンプレクス株式会社 前田 貴史
©︎ 本セッションの趣旨 • とあるチームにテストコードが根付いた経験を元に、テストコードが 根付くチームになるために考えたいことをさまざまな観点からお伝え できればと思います • テストコードに悩む方に明日から実践できるかもしれない何かを持ち 帰っていただけるセッションを目指します 2024 Simplex Inc.
©︎ スピーカー紹介 • 2010年シンプレクス入社 • FX、証券などの取引システムの開 発・運用 • 代表プロジェクトは資産運用アプリ 「NOMURA」(野村證券株式会 社)、マイナポータル新フロント 2024 Simplex Inc. (デジタル庁)など
©︎ About Simplex シンプレクスは1997年の創業以来、メガバンクや大手総合証券を筆頭に、日本 を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきまし た。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域 でもソリューションを展開しています。2019年3月にはAI企業のDeep Percept株 式会社、2021年4月には総合コンサルティングファームのXspear Consulting株 式会社がグループに加わり、創業時より付加価値の創造に取り組んできたシンプ レクスとワンチームとなって、公的機関や金融機関、各業界をリードする企業の デジタルトランスフォーメーション(DX)の推進を支援しています。 2024 Simplex Inc.
©︎ Simplexの基本コンセプト (1)お客様のビジネスを成功に導くテクノロジーパートナーとして、お客 様との直接取引(プライム受注)にこだわり、下請けに丸投げを行わない (2)コンサルティングからシステム開発、運用保守、改善提案まで、全 フェーズを一気通貫体制のもと、自社内で完遂する (3)ビジネスパーソンとして高いポテンシャルを持つ人材の獲得・育成 に注力し、ビジネスとテクノロジーに精通したハイブリッド人材全員が 「プレイヤー」として機能していく 2024 Simplex Inc. https://www.simplex.holdings/company/message/
©︎ 文脈合わせ • シンプレクスは主に金融機関のビジネスパートナーとして成長してき た企業。満たすべき品質の基準は非常に高い • 案件を受注 → 体制組成 → プロジェクト → リリース というパターン が多いが、リリース後も継続的にエンハンスを行い、お客様のビジネ スに伴走することが基本 2024 Simplex Inc.
©︎ わたしの過去のやらかし 2024 Simplex Inc.
©︎ 過去のやらかし わたし「今回のプロジェクトこそは、しっかり自動テストを書こう!」 わたし「自動テストをしっかり書いて結合テスト工程の工数を減らそ う!」 2024 Simplex Inc.
©︎ 過去のやらかし わたし「みんな!カバレッジ100%を目指すんや!」 みんな「は…はい 」 2024 Simplex Inc.
©︎ 過去のやらかし (リリース後) わたし「追加開発の依頼きたぞ」 わたし「うーん…このテストなんでこけてるんや?」 わたし「ちょっと時間ないから @Ignore しとくか…」 2024 Simplex Inc.
©︎ 過去のやらかし (リリース後) わたし「うーん… @Ignore 増えてきたな」 わたし「このテスト、クラスごと消すか…」 2024 Simplex Inc.
©︎ 頑張って書く →一定期間経ったら消える → また頑張って書く →… この負のサイクルを断ち切ることは できないか? 2024 Simplex Inc.
©︎ [再掲] 本セッションの趣旨 • とあるチームにテストコードが根付いた経験を元に、テストコードが 根付くチームになるために考えたいことをさまざまな観点からお伝え できればと思います • テストコードに悩む方に明日から実践できるかもしれない何かを持ち 帰っていただけるセッションを目指します 2024 Simplex Inc.
©︎ テストコードが「根付いた」 チームの特徴 2024 Simplex Inc.
©︎ チーム結成時点 • プロダクトはスマホアプリ • スマホアプリはFlutter • サーバーサイドはJava(SpringBoot) • テストコードを書いたことがないメンバーのほうが多数 • 過去にテストコードを書いたことがあったとしても、自発的にテスト コードを書くほどには慣れ親しんでいない 2024 Simplex Inc.
©︎ チーム結成から半年後 • 全員が日常的にテストコードを書く • CIサーバーでテストが失敗すると、作業を中断してすぐに直す • 日常的にリファクタリングしている(テストコードも) • 毎日お客様に「動くソフトウェア」を届けている - 日によっては数回/日で届けている • ミューテーションテストで自動テストの品質をあげようとしている 2024 Simplex Inc.
©︎ チームメンバーへの インタビュー 2024 Simplex Inc.
©︎ なんでテストコード 書くようになったんですか? わたし だって書かないと 不安なんですよ Aさん 2024 Simplex Inc.
©︎ なんでテストコード 書くようになったんですか? わたし 自分が書いたコードがバグってて、 チームに迷惑をかけることが多くて 辛かったんですよね。 テストが客観的に 動作を保証してくれるのが嬉しかった。 Bさん 2024 Simplex Inc.
©︎ テストコードが 自信を育てる 一度自信を持ってコードが書ける状 態を体験すると、元の状態に戻れな くなる Test Yourself - テストを書くと何がどう変わるか(ソフトウェアテストシンポジウム 2014 北海道基調講演)| https://www.slideshare.net/t_wada/jasst-2014-hokkaidotwadatdd 2024 Simplex Inc.
©︎ なんでテストコード 書くようになったんですか? わたし だって楽しいじゃないですか。 Cさん 2024 Simplex Inc.
©︎ 「めんどくさいけどちゃんとやる」は 「楽しいからやる」に勝てない ” ぼくはテストの人だと思われてるけど、テストはすごく嫌いだったんですよ。自動テストをしてなかった ころ。自分が書いたコードとか自分が書いたシステムに対して動作確認するとか、画面をいじって動くかど うか調べるとかいうのがめんどくさかった。あんまり好きではなかった。 ” 自動テストとかテスト駆動開発に出会ったら、それ(動作確認)を「コードで書いていいよ」って言われ てるように感じたんですね。めんどくさいことがとにかく好きじゃなかったので、そんなことやるくらいな らもっとコード書きたいと思うたちだったんだけど、JUnitとかに出会ったら、「いや、動作確認もコード で書いていいよ」って言われてるように僕は思ったんですね。そしたら突然、プログラミング対象が倍以上 になったんですよね。めちゃくちゃうれしい。めんどくさいを楽しいにそのまんまガンガン変換してできる ようになったし、しかも楽しいプログラミングをしてたら開発が楽になってきた。これはうれしい。 2024 Simplex Inc. Sideshow 9. Master of Writing Test Code texta.fm | https://open.spotify.com/episode/7FyQqWPds37ysNTQrczr6f
©︎ ここまでのまとめ • テストコードを書いたことがないメンバーが多かったチームが、しば らくすると日常的にテストコードを書くようになっていた - テストを書くようになった理由を聞いてみると、「自信をもつた め」「楽しいから」といった心理的なものだった 2024 Simplex Inc.
©︎ テストを書くために使ったツールなど 2024 Simplex Inc.
©︎ 2024 Simplex Inc.
©︎ クライアント-サーバー間でやりとりするJSONの定義を固めたい! JSON 2024 Simplex Inc.
©︎
MockMvc
@SpringBootTest
@AutoConfigureMockMvc
class NewsControllerTest {
@Autowired
public MockMvc mockMvc;
}
@Test
void t0() throws Exception {
…
mockMvc
.perform(
get("/news")
.queryParam("newsId", newsId)
.queryParam("date", date)
)
.andExpect(status().isOk())
.andExpect(content().json(json));
}
2024 Simplex Inc.
これから開発する機能で使う、クライ
アント-サーバー間でやり取りする
JSONの定義を固めたい!
😊 直感的な書き方ができる
😕 SpringBootTestを使うので時間がか
かる
©︎ MockMvc 2024 Simplex Inc.
©︎ 外部サービスから「これが戻ってきたらこうする」を検証したい! MockMvc JSON 2024 Simplex Inc.
©︎ MockRestServiceServer @SpringBootTest class NewsControllerTest { @Autowired public RestTemplate restTemplate; @Test void t0() { ... MockRestServiceServer mockServer = MockRestServiceServer.bindTo(restTemplate).build(); mockServer .expect( requestTo(url) ) .andRespond( withSuccess(json, APPLICATION_JSON) ); ... } } 2024 Simplex Inc. 外部サービスから「これが戻ってきた らこうする」を検証したい! 😊 直感的な書き方ができる 😊 HTTPのステータス、レスポンスヘッ ダー、ボディーなど、細かく設定可能 😕 SpringBootTestを使うので時間がか かる
©︎ MockMvc 2024 Simplex Inc. MockRestServiceServer
©︎ データベースと問題なくやりとりできているか検証したい! MockMvc 2024 Simplex Inc. MockRestServiceServer
©︎ Testcontainers データベースと問題なくやり取りできてい るか検証したい! 😊 JUnitからコンテナを起動できる 😊 ローカルでもCIサーバー上でも再現する https://testcontainers.com/ 忠実性の高いテストを書ける 😕 コンテナを立ち上げるので時間がかかる 2024 Simplex Inc.
©︎ MockMvc 🎉 2024 Simplex Inc. MockRestServiceServer
©︎ 2024 Simplex Inc.
©︎ 個人的な悪い癖 • ツールの使い方を覚えると、全ての場面で使いたくなってしまう 2024 Simplex Inc.
©︎ [再掲] 過去のやらかし (リリース後) わたし「追加開発の依頼きたぞ」 わたし「うーん…このテストなんでこけてるんや?」 わたし「ちょっと時間ないから @Ignore しとくか…」 2024 Simplex Inc.
©︎ カバー範囲の広い テストの問題 忠実性(本物の挙動を反映している 度合い)は高い一方で、記述コス ト・実行コストに加え、テストが失 敗した際の調査・復旧コストも高い (問題の切り分けが難しい) 第5回 テストピラミッド 〜自動テストの信頼性を中長期的に保つ最適なバランス〜 | https://gihyo.jp/dev/serial/01/savanna-letter/0005 2024 Simplex Inc.
©︎ テストケースの数 2024 Simplex Inc.
©︎ Testcontainersを使ったテスト テストケースの数 2024 Simplex Inc.
©︎ Testcontainersを使ったテスト Testcontainersは使わないが、 Springの機能を使ったテスト テストケースの数 2024 Simplex Inc.
©︎ Testcontainersを使ったテスト Testcontainersは使わないが、 Springの機能を使ったテスト ピュアなJUnitの機能 だけを使うテスト テストケースの数 2024 Simplex Inc.
©︎ ナイステスト!の要件 以下を満たすテストはナイステスト!と言いたくなる。 • プロダクションコードを書き換えた時、 • 修正に失敗していることに気づくまでの時間が短い • なぜその修正だとダメなのかを理解できるまでの時間が短い → ナイステスト!が増えれば増えるほど、テストコードを書くのが楽し くなり、自信を持って前に進むことができるようになる 2024 Simplex Inc.
©︎ 良いテストコードの指標 • Fast = 高速に動作すること • Independent = 互いに依存関係がなく、独立していること • Repeatable = いつでもどこでも繰り返し再現可能であること • Self-Validating = テストコード自身が検証を行うこと • Timely = 書かれるべきときに書かれていること 2024 Simplex Inc. https://t-wada.hatenablog.jp/?page=1586393100
©︎ 指標 満たされないと… 意味 1回の実行に時間がかかるのでまとめて作業 Fast 高速に動作すること → 何が問題なのかわからない… → 結局時間がかかる A→B→Cなら成功するけどC→B→Aなら失敗する Independent 互いに依存関係がなく、独立 → Aはもう要らないのに消せない していること → 最悪、「なぜ成功しているのかわからない」状態に ・ローカルでは成功するけどCIサーバーでは失敗 Repeatable いつでもどこでも繰り返し再 ・特殊日によっては失敗 現可能であること など Self-Validating テストコード自身が検証を行 テストコードが出力するテキストを人間が検証しないといけない、など → 気軽にテスト実行ができなくなる うこと Timely 書かれるべきときに書かれて ※ 書かれてから時間が経ったコードにテストを書くよりは、書いた直後にテスト を書いた方が楽 いること 2024 Simplex Inc. https://t-wada.hatenablog.jp/?page=1586393100
©︎ ここまでのまとめ • テストコードを書いたことがないメンバーが多かったチームが、しば らくすると日常的にテストコードを書くようになっていた - テストを書くようになった理由を聞いてみると、「自信をもつた め」「楽しいから」といった心理的なものだった • ナイステスト!と言いたくなるテストが増えれば増えるほど、テスト コードを書くのが楽しくなり、自信を持って前に進むことができるよ うになる 2024 Simplex Inc.
©︎ ナイステスト!を生む プロダクションコード 2024 Simplex Inc.
©︎ 楽しくないテスト テストコード • スタブを用意したり、前提になる 複雑なデータを用意する必要があ る • 大抵実行に時間がかかる https://martinfowler.com/bliki/PresentationDomainDataLayering.html 2024 Simplex Inc. • 壊れた時に直すコストが高い
©︎ HumbleObject プログラムの構成要素のうちできる だけ多くのロジックを、本質的にテ https://martinfowler.com/bliki/HumbleObject.html ストが困難な部分からテストフレン ドリーな部分に移動させ、テスト不 可能なオブジェクトを謙虚 (humble)にする。 2024 Simplex Inc.
©︎ 👈 Humbleに! 楽しいテスト • スタブが不要 テストコード • 複雑な前提データも不要 👈 Humbleに! • 実行時間が短く、迅速にフィード バックをくれる • 壊れた時も直しやすい https://martinfowler.com/bliki/PresentationDomainDataLayering.html 2024 Simplex Inc.
©︎ ここまでのまとめ • テストコードを書いたことがないメンバーが多かったチームが、しばらく すると日常的にテストコードを書くようになっていた - テストを書くようになった理由を聞いてみると、「自信をもつため」「楽 しいから」といった心理的なものだった • ナイステスト!と言いたくなるテストが増えれば増えるほど、テストコー ドを書くのが楽しくなり、自信を持って前に進むことができるようになる • プロダクションコードの設計が、ナイステスト!と言いたくなるテストを 生みやすくする 2024 Simplex Inc.
©︎ 「根付かなかった」チームと 「根付いた」チーム、 何が違ったのか? 2024 Simplex Inc.
©︎ チームを取り巻く環境 • 週に一度、丸一日お客様と一緒に過ごしていた • 毎日、その日完成した機能を見ていただいていた • 日々、チームはお客様のビジネスにおける業務ルールをどのように コードで表現するかについて議論を重ねていた • ホワイトボードに図を書いては、コードに反映するのを繰り返して いた 2024 Simplex Inc.
©︎ 違ったのは自分 • 「根付かなかった」チームでは自分がお客様と開発者の間のプロキシになっ ていた • 「根付いた」チームでは開発者が直接お客様と対話していた • 直接対話するからこそ、お客様のビジネスを理解しようとしていた • 理解したことをできる限りコード(プロダクションコードとテストコー ド)に表現しようとしていた • だからこそ、自分たちの理解が誤っている可能性を知らせてくれるテスト コードを大事にしていた 2024 Simplex Inc.
https://bliki-ja.github.io/CustomerA nity ffi ©︎ 2024 Simplex Inc.
“ トップクラスのエンタープライズソフトウェア開発者になるために必要なも のは何かという話になると、だいたいフレームワークや言語の知識や複雑な アルゴリズムやデータ構造を理解する能力だろうという方向に話が進む。 だ が、プログラマや開発チームにとって最も重要なのは、私が「顧客親近性」 と呼んでいるものだ。 これは、ソフトウェアが対処すべきビジネスの問題、 そして、そのビジネスの世界に生きている人々に対する関心および親密さを 表すものである。 2024 Simplex Inc. https://bliki-ja.github.io/CustomerA nity ffi ©︎ 顧客親近性
“ ビジネスソフトウェアの真の知的挑戦とは、ソフトウェアがビジネスにとっ てどのように貢献できるかを見つけ出すことである。 そのためには技術スキ ルとビジネス知識の両方が必要となる。 ビジネス側の人間と密接に仕事をす ることでビジネス知識を高めていき、 また同時に、顧客満足を目指してい く。 これこそがエンタープライズソフトウェアの楽しみである——そしてこれ が、よい製品を作り出すための鍵となるモチベーションになる。 2024 Simplex Inc. https://bliki-ja.github.io/CustomerA nity ffi ©︎ 顧客親近性
©︎ 顧客親近性 2024 Simplex Inc.
©︎ 顧客親近性 ドメインへの 執着 2024 Simplex Inc.
©︎ 顧客親近性 ドメインへの 執着 ビジネス ルール以外を Humbleに 2024 Simplex Inc.
©︎ 顧客親近性 ドメインへの 執着 ナイステスト! の増加 2024 Simplex Inc. ビジネス ルール以外を Humbleに
©︎ 顧客親近性 自信と 「楽しい!」の 増加 ナイステスト! の増加 2024 Simplex Inc. ドメインへの 執着 ビジネス ルール以外を Humbleに
©︎ 学び • 開発者がドメインを探求しやすいように、顧客親近性を育みやすい環 境を整えるのがリーダーのすべきことだった • 顧客親近性が育まれれば、自然とドメインの知識を学びたくなり、テ ストコードで知識を保護したくなる • 結果、自信を持たせてくれて「楽しい」と思えるテストコードが増え れば、テストコードは自然とチームに根付く 2024 Simplex Inc.