STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
•
3 j'aime•16,350 vues
STAC2015の講演3での発表資料です。
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (15)
Similaire à STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
Similaire à STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015 (20)
Plus de Yahoo!デベロッパーネットワーク
Plus de Yahoo!デベロッパーネットワーク (20)
Dernier
Dernier (8)
STAC2015 講演3 広告システム刷新よもやま話〜テストが当たり前となるまでにやったこと #stac2015
- 2. ⾃自⼰己紹介 YJ⼊入社前 Sierな世界の住⼈人。 受託案件をこなす業務システム開発 のエンジニア。 YJ⼊入社後 BtoBなWebサービス開発へ。 Web系と⾔言いつつエンタープライズ 系っぽいシステムの開発に携わる。 • 名前：森下⼤大介 • 年年齢：40 • 職歴：2011年年にYJに中途⼊入社 • ⾔言語：C/C++/Java
- 4. 4P本⽇日の内容 • バックグラウンド • 取り組んだこと • やったことその０：体制づくり • やったことその１：プログラミング⾔言語を変える • やったことその２：テストができるアーキテクチャに • やったことその３：テスト向けDSL (Spock) • やったことその４：CI/CD, 静的解析 • やったことその５：インタフェース定義⾔言語 • 振り返っての所感
- 5. バックグラウンド
- 6. 当時困っていたこと 「なんか妙につらい」 例例１：⼩小改修なのにつらい typo修正したいだけなのに・・・ -‐‑‒ ユニットテストがない -‐‑‒ コンパイラ、型がない -‐‑‒ IDE使ってない 例例２：結合がつらい なかなかつながらない・・・ -‐‑‒ APIIFドキュメントが⼿手書き、書き⽅方が統⼀一され てると⾔言えない -‐‑‒ APIIFドキュメントの書き⼿手と読み⼿手でお互いに 認識識がズレてる -‐‑‒ APIIFドキュメント通りに実装されていない。 例例３：なんとなく動いてつらい LLの柔軟さが裏裏⽬目に・・・ -‐‑‒ 存在しないメソッドコールしても動く。 -‐‑‒ 間違った型で引数受け取っても動く。
- 7. 何が起きてる？ 考察１：「⼤大規模」で「複雑」 サービスが育った結果・・・ -‐‑‒ 道具の助け無しで -‐‑‒ ⼈人⼿手と記憶と努⼒力力と根性で -‐‑‒ がんばれる規模をこえている 考察２：道具とやり⽅方が合ってない ちゃんとデータを扱いたいのに -‐‑‒ 型宣⾔言が無い -‐‑‒ コンパイラに頼れない -‐‑‒ テストを仕掛けられない 考察３：積み重なる技術負債 やり⽅方そのままで -‐‑‒ 既存コンポーネントは拡張され -‐‑‒ 新規コンポーネントが追加され -‐‑‒ そしてそこにテストは無い
- 9. ⽬目指したこと 変わるべきは「⾃自分達」 • ３倍早く • やりやすく • 確実に 開発できる強いエンジニアになること。 システム刷新は「結果」 • ⾃自分の変化がアウトプットを変える。 • でも結果を出すことも重要。 • 結果で証明する。 ３倍早い開発スピード
- 10. 取り組んだこと
- 13. 求めた効果は、 しょうもないレベルの間違い を動かすまでもなく潰せるこ と。 これができないと、typo修正 すらおそろしくなる。 • 動かして全確認が必要 • 漏漏れが無いか確証が持てない。 考えたのは以下あたり。 • C++ • Java • Scala この条件でいくと、現実的な 選択肢はだいぶ絞られる。
- 14. 選んだのは Java Webサービス系開発者に はとかく嫌われる、ディ スられるが・・・ 副次的なものとして • 豊富なOSS • 統合開発環境の活⽤用 • 優れた静的解析ツール これで得られたもの • コンパイルできる！ • 厳密な型定義できる！ • 優れたメモリ管理理(GC) • 実⾏行行時最適化(JIT) • デバッガ、解析ツール
- 15. やったことその２ テストできる アーキテクチャに テストできないとは？ • 動かす準備が⼤大変 • ブラックボックステストになる • CI/CDの中で実⾏行行できない • etc… 根本的な原因として、プロダクトが 「モノリシック」なカタマリになっ ているためと仮定。 ユニットテストしたい単位で単独で 動かせない状態。 ただ、現⾏行行システムで既にサーバー 分割とAPI化によって準マイクロ サービス的な構成となっていた。 おかげで考慮対象はサーバー上で動 くアプリケーションコードのみで済 んだ。
- 16. 16Pモノリシックなコードの例例 これらは⼀一⾒見見するとA, B, Cというクラスに分 割されているように⾒見見えるが・・・ public class A { public void x() { B b = new B(); b.y(); } } public class B { public void y() { C c = new C(); c.z(); } } public class C { public void z() { DB操作とか } }
- 17. 17Pこれにテストケースを仕掛けてみると・・・ public class A { public void x() { B b = new B(); b.y(); } } public class B { public void y() { C c = new C(); c.z(); } } public class C { public void z() { DB操作とか } } TestCaseA (A, B, Cの複合テスト) Class AにテストケースつくるとB, Cも必ず くっついて来て単独テストにならない。 TestCaseB (BとCの複合テスト) TestCaseC (これはまだ単独)
- 18. ポイントは、 「呼び出し先の実装クラスを⾃自分で newしていること」 これだとクラス同⼠士が密結合する。 このようなことから、 「テストできるような構造じゃない からやらない」 という結論論となり、放置される。 この状態で無理理にテストケースを仕 掛けたとしても、 • 実⾏行行条件が増える • バリエーションが掛け算で増加 • メンテ、問題箇所の特定が困難 これを解決するために全⾯面的に採⽤用 したアーキテクチャが 「Dependency Injection」
- 19. 19PDI(JavaでSpringFramworkの場合) public class Aimpl implements A { @Autowired private B b; public void x() { b.y(); } } public class Bimpl implments B { @Autowired private C c; public void y() { c.z(); } } public class Cimpl implements C { public void z() { DB操作とか } } 実装クラスとインタフェースを分離離、コール先のインタフェースのみ認識識 し、実装インスタンス(Dependency)は外部から注⼊入(Injection)。
- 20. 20Pこれにテストケースを仕掛けてみると・・・ public class Aimpl implements A { @Autowired private B b; public void x() { b.y(); } } 今まではA単独のテストができなかったが、依存するBをモック化するこ とでテストしたい処理理だけに対して確認を⾏行行えるようになる。 class TestCaseA { def testA() { def a = new Aimpl() //モック注入 a.b = Mock(B.class) //テスト実行、assert a.x() } }
- 23. そこで選んだのが Spock Junitの上に構築されたものだが、 記述⾔言語は、JVM⾔言語の 「Groovy」 その上にテストを記述するための DSL(ドメイン固有⾔言語)が構築され ている。 主な機能としては • テスト実⾏行行 • BDD的なテスト記述⽂文法 • 柔軟なモック／スタブ⽣生成 • テストパターンデータの記述 特に良良いのが、Groovy⾃自体がJava よりも⾊色々省省略略して書けること。 テストコードはJava⾔言語では書き たくない。
- 24. 24PSpockによるテストコード例例 class SampleSTest extends Specification { def “データ更新テスト(#testname)”() { given: def target = new SampleImpl() target.x = Mock(X.class) when: def result = x.update(request) then: assert result == response where: testname | request | response “パターンA” | “foo1” | “bar1” “パターンB” | “foo2” | “bar2” } } テストケースで以下のようなブロックに区切って コードを書ける。 • givenがテスト対象のセットアップ • whenがテスト対象の実行 • thenがテスト結果の確認 • whereがテストデータ Mockの生成とその挙動も全てテストコードの中 で記述できるのが良いところ。 テストデータを複数件かけばその件数分で全 体をループして実行してくれる。 Groovyの型推論や省略記法も楽で助かる。
- 25. やったことその４ CI/CD, 静的解析 アーキテクチャとテストケースそれ ぞれのアプローチからテストができ ない理理由を取り除いた。 これでやっとCI/CDの中であたりま えにテストを⾏行行うようになった。 さらに⾏行行っていることその１ Cloverによるカバレッジ計測 さらに⾏行行っていることその２ Coverityによる静的解析 • Quality Advisor • Test Advisor
- 28. そこで導⼊入したのが インタフェース 定義⾔言語 当初はOSSの以下あたりを使えない かと検証したが、 • Googole ProtocolBuffer • Apache Thrift 以下の理理由から断念念 • バリデーションが表現できない • ドキュメントが⽣生成できない イチから以下を⾏行行いました。 • ⾔言語⾃自体の⽂文法設計 • コンパイラ開発 • Javaコードジェネレータ • ドキュメントジェネレータ • ドキュメント表⽰示サーバー
- 30. 振り返っての所感