Downloaded 14 times
![47Pテスト向けDSLの採用final SampleDao dao = context.mock(SampleDao.class);final List<Sample> expected = Arrays.asList(new Sample());Expectations mockConfig = new Expectations() {{oneOf(dao).findBySelector(with(new TypeSafeMatcherSimple<SampleSelector>() {@Overrideprotected boolean matchesSafely(SampleSelector item) {assertEquals(ids[0], item.getIds().get(0));assertEquals(ids[1], item.getIds().get(1));assertEquals(userStatuses[0], item.getUserStatuses().get(0));return true;}}));will(returnValue(expected));}};context.checking(mockConfig);JMockを利用したテストコードの一部。つらくないですか？](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjjugccc-cccf1-ad-business-system-reform-160523013204%2f75%2fjjug_ccc-ccc_f1-PHP-Java-47-2048.jpg&f=jpg&w=240)
![69Pインタフェース定義言語//IDLファイルの例namespace entity sample.entity;entity Sample {field Long id {valid min 1;valid max 100;}field String name {valid max 100;valid pattern ”^[a-zA-Z0-9¥¥-_]+$”;}}//生成Javaコードの例package sample.entity;public class Sample implements Entity {@CheckNumber(min=1, max=100)private Long id;public void setId(Long id) { …. }public Long getId() { …. }@CheckString(max=100,pattern=“^[a-zA-Z0-9¥¥-_]+$”)public String name;public void setName(String name) { …. }public String getName() { …. }}IDLコンパイラでJavaコード生成IDLで記述したデータ構造(entity)のJavaコード生成例。この場合はバリデーション用アノテーション付きのPojoが生成される。](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fjjugccc-cccf1-ad-business-system-reform-160523013204%2f75%2fjjug_ccc-ccc_f1-PHP-Java-69-2048.jpg&f=jpg&w=240)
Uploaded byYahoo!デベロッパーネットワーク
2,611 views
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
JJUG CCC 2016 Springの以下のセッションで発表した際の資料です。http://www.java-users.jp/?page_id=2396#F-1
More Related Content
What's hot
Similar to #jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
More from Yahoo!デベロッパーネットワーク
#jjug_ccc #ccc_f1 広告システム刷新の舞台裏 - PHPからJavaに変えてみました
- 1.
- 2.自己紹介YJ入社前Sierな世界の住人でした。受託案件をこなす業務システム開発のエンジニア。YJ入社後BtoBなWebサービス開発へ。Web系と言いつつエンタープライズ系っぽいシステムの開発に携わる。• 名前：森下大介• 年齢：41•職歴：2011年にYJに中途入社• 言語：C/C++/Java/PHP/Node.js
- 3.
- 4.
- 5.5P本日の内容• バックグラウンド• 取り組んだこと•やったことその０：体制づくり• やったことその１：プログラミング言語を変える• やったことその２：テストができるアーキテクチャに• やったことその３：テスト向けDSL (Spock)• やったことその４：CI/CD, 静的解析• やったことその５：インタフェース定義言語• 振り返っての所感
- 6.
- 7.7P入社当時のシステムの特徴：利用言語、道具• 言語：– PHPメイン–たまにバッチ系にPerl– 一部のライブラリはC + PHP Extension• 道具：– ほとんどの人がvim, emacs等を使用– IDEはほとんど使われていない– テストはほぼブラックボックステストのみ
- 8.8P入社当時のシステムの特徴：システム構成• システム構成– FE/BEは明確に分離、BEはWebAPI化–マイクロサービスほどでは無いが分散システム化• このおかげで・・・– 機能ごとにスケールができた– 機能ごとにアップデートができた
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.18P当時のエンジニアの心中このままだとヤバイのは薄々感じてる。感じてるけど・・・– 目の前の巨大システムは売上を現実にあげている– ビジネス拡張のための案件はひっきりなし–変えるには根本的な手当が必要・・・– どーすりゃいいのこれ？
- 19.
- 20.20P目指したことシステム刷新は「結果」• 自分の変化がアウトプットを変える。• でも結果を出すことも重要。•結果で証明する。変わるべきは「自分達」• ３倍早く• やりやすく• 確実に開発できる強いエンジニアになること。「３倍早い開発スピード」
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.33Pプログラミング言語を変えるこれで得られたもの• コンパイルできる• 厳密な型定義ができる•優れたメモリ管理(GC)• 実行時最適化(JIT)• デバッガ、解析ツール副次的なものとして• 豊富なOSS• 統合開発環境の活用• 優れた静的解析ツール
- 34.
- 35.35Pテストできるアーキテクチャに「テストできない」とはどういう状況？• 動かす準備が大変• CI/CDの中で実行できない•ブラックボックステストになる• etc…
- 36.
- 37.37Pモノリシックなコードの例これらは一見するとA, B, Cというクラスに分割されているように見えるが・・・publicclass 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操作とか}}
- 38.38Pこれにテストケースを仕掛けてみると・・・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(これはまだ単独)
- 39.
- 40.
- 41.41PDI(JavaでSpringFramworkの場合)public class AimplimplementsA {@Autowiredprivate B b;public void x() {b.y();}}public class Bimplimplments B {@Autowiredprivate C c;public void y() {c.z();}}public class Cimplimplements C {public void z() {DB操作とか}}実装クラスとインタフェースを分離、コール先のインタフェースのみ認識し、実装インスタンス(Dependency)は外部から注入(Injection)。
- 42.42Pこれにテストケースを仕掛けてみると・・・public class AimplimplementsA {@Autowiredprivate B b;public void x() {b.y();}}今まではA単独のテストができなかったが、依存するBをモック化することでテストしたい処理だけに対して確認を行えるようになる。class TestCaseA {def testA() {def a = new Aimpl()//モック注入a.b = Mock(B.class)//テスト実行、asserta.x()}}
- 43.
- 44.
- 45.
- 46.
- 47.47Pテスト向けDSLの採用final SampleDao dao= context.mock(SampleDao.class);final List<Sample> expected = Arrays.asList(new Sample());Expectations mockConfig = new Expectations() {{oneOf(dao).findBySelector(with(new TypeSafeMatcherSimple<SampleSelector>() {@Overrideprotected boolean matchesSafely(SampleSelector item) {assertEquals(ids[0], item.getIds().get(0));assertEquals(ids[1], item.getIds().get(1));assertEquals(userStatuses[0], item.getUserStatuses().get(0));return true;}}));will(returnValue(expected));}};context.checking(mockConfig);JMockを利用したテストコードの一部。つらくないですか？
- 48.
- 49.
- 50.50Pテスト向けDSLの採用Junitの上に構築されたものだが、記述言語は、JVM言語の「Groovy」その上にテストを記述するためのDSL(ドメイン固有言語)が構築されている。主な機能としては• テスト実行• BDD的なテスト記述文法•柔軟なモック／スタブ生成• テストパターンデータの記述特に良いのが、Groovy自体がJavaよりも色々省略して書けること。テストコードはJava言語では書きたくない。
- 51.51PSpockによるテストコード例class SampleSTest extendsSpecification {def “データ更新テスト(#testname)”() {given:def service= new SampleServiceImpl()def dao = Mock(SampleDao.class)1 * dao.update(_) >> responseserivce.dao = daowhen:def result = service.update(request)then:assert result == responsewhere:testname | request | response“パターンA” | “foo1” | “bar1”“パターンB” | “foo2” | “bar2”}}テストケースで以下のようなブロックに区切ってコードを書ける。• givenがテスト対象のセットアップ• whenがテスト対象の実行• thenがテスト結果の確認• whereがテストデータMockの生成とその挙動も全てテストコードの中で記述できるのが良いところ。テストデータを複数件かけばその件数分で全体をループして実行してくれる。Groovyの型推論や省略記法も楽で助かる。
- 52.
- 53.
- 54.54PCI/CD, 静的解析CI/CDの中では以下の様なテストや解析を実施• SpockによるSテストケース実行•Cloverによる詳細なカバレッジ計測• Coverity QualityAdvisorによるコード解析• Coverity TestAdvisorによるテスト解析• Frisbyを使ったWebAPIのSmokeテスト
- 55.
- 56.
- 57.
- 58.58Pインタフェース定義言語APIを「提供」する側では、• 人がAPIIFを考えて• それを頑張ってドキュメントとして書く。•それを元に実装する。APIを「利用」する側では、• 人がAPIIFドキュメントを読んで理解して、• そのAPIを利用する処理を実装する。
- 59.
- 60.
- 61.
- 62.62Pインタフェース定義言語当初はOSSの以下あたりを使えないかと検証したが、• Googole ProtocolBuffer•Apache Thrift以下の理由から断念• 入力値バリデーションが表現できない• ドキュメントが生成できない
- 63.63Pインタフェース定義言語一から以下を行いました。• 定義言語自体の文法設計• コンパイラ開発•Javaコード・ドキュメントジェネレータ開発• ドキュメント表示サーバー開発• 入力値バリデーションエンジン開発
- 64.
- 65.
- 66.
- 67.
- 68.68Pインタフェース定義言語IDLから生成されるJavaコードは以下。• Context (データ操作のコンテキスト情報)•Entity (Pojoデータオブジェクト)• Enum (Enum系項目の値定義)• Error (エラーコード一覧)• JAX-RSインタフェース(APIエンドポイント)
- 69.69Pインタフェース定義言語//IDLファイルの例namespace entity sample.entity;entitySample {field Long id {valid min 1;valid max 100;}field String name {valid max 100;valid pattern ”^[a-zA-Z0-9¥¥-_]+$”;}}//生成Javaコードの例package sample.entity;public class Sample implements Entity {@CheckNumber(min=1, max=100)private Long id;public void setId(Long id) { …. }public Long getId() { …. }@CheckString(max=100,pattern=“^[a-zA-Z0-9¥¥-_]+$”)public String name;public void setName(String name) { …. }public String getName() { …. }}IDLコンパイラでJavaコード生成IDLで記述したデータ構造(entity)のJavaコード生成例。この場合はバリデーション用アノテーション付きのPojoが生成される。
- 70.70Pインタフェース定義言語//IDLファイルの例namespace service sample.jaxrs;serviceSampleService {path /SampleService;operation Response add(Sample sample);operation Response set(Sample sample);}//生成Javaコードの例package sample.jaxrs;@Path(“/SampleService)public interface SampleService {@Path(“/add”)@POSTpublic Response add(Sample sample);@Path(“/set”)@POSTpublic Response set(Sample sample);}IDLコンパイラでJavaコード生成IDLで記述したWebAPIエンドポイントのJavaコード生成例。この場合はJAX-RSのアノテーション付きインタフェースが生成される。
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.77P問題検出はできるだけ前工程に開発者の手元を離れる直前まで、やれる事をやる。• IFを結合前に安定させられるIDL• コンパイルと型宣言•テストを書いて手元でもCI/CDでも実行• Coverityの静的解析。
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.