JJUG CCC 2015 Spring

1. Java Web アプリケーショ
ンのテスティングの話
JJUG CCC 2015 Spring
tokuhirom

2. 初心者向けっちゃ
初心者向け

3. コミュニティイベントなので
コミュニティからのフィード
バック重視

4. 答えを提供するよりは
議論の元を提供する感じで

5. 自己紹介

6. 自己紹介なんて
不要だと思うかもしれません
が｡｡

7. 業種の前提が無いと､
聞いても無意味

10. 自社サービスの
ウェブアプリケーション
の開発

11. 一昨年まで Perl 書い
てたけど去年から Java

12. Native App 用の API
サーバー等が主

13. Form Webapp
multipart/form-data
application/x-www-form-urlencoded
HTML
従来手法

14. iPhone
App Webapp
Android
App
AngularJS
App
JSON
JSON
近年のアプリ

15. 開発手法の話

16. Agile

17. それをAgileと呼ぶなら
それはAgileなのだろう

18. 開発の手順
Server
Spec
Client
QA

19. Iterative
1.2
1.1
2.0
2.1

20. 開発に利用している
コンポーネント

21. Apache Tomcat MySQLJava8

22. 普通だ!

23. 自己紹介終わり｡

24. 本編です

25. 質問は随時叫ぶなり手を
あげるなりしてください｡

26. 原則

27. 手動テスト最高です
ね!!

28. (CENSORED)

29. ネイティブアプリ等は
機種ごとの差異なども
あるので
最終的には必要

30. どこまで自動化するか

31. 手動でやるよりも
自動でやったほうが
楽になりそうだな~って
ところまでやる｡

32. ここ､テスト書いておかない
と後で壊れそうだな
というところを､｢契約｣とし
て
書いておく

33. Web Application でのテ
スト､どのレイヤでやるか｡

34. どこまでスタブにする
か

35. 近代的WebApp
Browser Controller Model RDBMS
外部API

36. どこのレイヤでテスト
する?

37. Model のテストを手厚
くやろう｡

38. どうやる?

39. 悩みどころ

40. Q. RDBMSまわりの
テスト､どうやるか?

41. A. RDBMSとのつきあ
いかたによる

42. 深い付き合い
浅い付き合い

43. 1. RDBMS を絞り尽く
したい派

44. SQLをゴリゴリ
書きたい

45. 2. JPA にすべてを委ね
るよって人

46. JPAがRDBMSの差異
を吸収してくれる｡｡

47. はず

48. RDBMS に依存しない
実装を求める

49. H2 でテストするぞ!!!

50. 僕の場合

51. 1 です｡

52. JPA は使わないので｡｡
(CENSORED)

53. SQL書きたいよ?

54. 一番テストしたいのは
RDBMS とのつなぎ込み部分

55. RT : WEB+DB システムとは
SQL と入出力仕様だ

56. というわけで､MySQLを利用
したテストの仕方をご紹介し
ます｡

57. よ~し､パパ
MySQL を maven から
起動しちゃうぞ~

58. (CENSORED)

59. local に立ってる
MySQL 使ってこ

60. CREATE DATABASE
proj_test_deadbeef;
プロジェクト名 ランダム生成文字列

61. スキーマのSQLを流し
込む!!!

62. for (SHOW TABLES) {
DELETE FROM $_;
}
@Before

63. マスターデータを
INSERTする

64. 自動生成したDBへの接続情報は
DI かなにかでがんばって
設定しよう!!

65. DB のテストに関する
知見は以上になります｡

66. 休憩

67. 外部APIのテスト

68. ところで､最近話題の
microservices

69. SOA でもなんでもい
いですが……

70. 僕の周りでは10年ぐらい前
疎結合ウェブアプリケーション
と呼んでました｡

71. コンポーネントを
細かい httpd に分けて
HTTP で通信してこ↑

72. メリット:
分業しやすい
変更の影響範囲が明確

73. 弊社でも､
バズワードが出る前から
実践されております｡
(CENSORED)

74. しかし､
テストがやや
やりにくい｡

75. どうするか?

76. クライアントライブラ
リを DI で置き換える?

77. 速い｡

78. テスト範囲が狭くなっ
て良くない面がある｡

79. 結合テストを別途行う
ならいいけど｡｡

80. httpd を起動して
モックサーバーを実行する

81. Embedded Jetty

82. servlettester-jetty
github.com/tokuhirom/
servlettester-jetty

83. JettyServletTester.runServlet((req, resp) -> {
resp.getWriter().print("Hey");
}, (uri) -> {
try (CloseableHttpClient client =
HttpClientBuilder.create()
.build()) {
HttpGet request = new HttpGet(uri);
try (CloseableHttpResponse resp =
client.execute(request)) {
String body = EntityUtils.toString(resp.getEntity(),
StandardCharsets.UTF_8);
assertEquals("Hey", body);
}
}
});

84. http://localhost:12800/

85. httpd あげるの無駄な
のでは????

86. 無駄だけど､jetty なら起
動速いし気にならない｡

87. DB関連のほうが十分
に遅いので｡｡

88. 実際には､もっとシン
プルに｡｡

89. apimock
https://github.com/
tokuhirom/apimock

90. Sinatra風にサーバー側
実装を書ける

91. @Test
public void test() {
mockApi(mock -> {
mock.get(“/api/member/detail“,c -> {
return ImmutableMap.of(“hoge”, “fuga”);
});
},
() -> {
assertEquals(”fuga}”,
injector.get(Client.class).getMember(1)
.getHoge()
);
}
}

92. HTTPの通信を細かく
書けないと､
Regression Test
書きづらい｡

93. 外部 API のテストに関する
知見は以上になります｡

94. 休憩

95. コントローラのテスト

96. コントローラのテスト､
どうやるか

97. API サーバー
のテスト

98. 極めて書きやすい｡

99. httpd をあげて
Apache HttpClient
でアクセスする｡

100. servlettester-jetty

101. JettyServletTester.runServlet(
new MyServlet(), (uri) -> {
// your test code
}
);

102. 実際のテストコードで
は｡｡｡

103. ControllerTestBase クラ
ス的なので自動的にサー
ブレット立ち上げる｡

104. @Test
public void test() {
http.get(“/api/member/“)
.isOK()
.contentContains(“hogehoge”);
}

105. JSON API だったらど
うすんの?

106. @Test
public void test() {
val req = new Req(“hoge”, “fuga”);
Res res = mech2.postJSON(“/api/
member/register“, req)
.isOK()
.parseJSON(Res.class);
assertThat(res.getName())
.isEqualTo(“hoge”);
}

107. @Test
public void test() {
http.post(“/api/member/create“)
.param(“name”, “John”)
.isOK()
.contentContains(“hogehoge”);
}

108. HTML のフォームとか
……?

109. あんま真面目にテスト
してない｡｡

110. 人力のテストでカバー
できるので｡｡

111. HTML 変わりまくるので､自動
化テストの手間が
見合わない｡

112. コントローラのテスト
の話は終わり｡

113. ダミーデータの作成

114. public class TestBase {
@Inject
protected Creator create;
}

115. @Test
public void test() {
Member member =
create.member();
Blog blog = create.blog(member);
// …
}

116. fixture.yml 的なの
メンテナンスが面倒

117. Web 屋さん､
Excel 嫌いな人もいるので｡｡

118. ダミーデータ作成の話､
終わり｡

119. テストライブラリ
どれがいいのか､という話

120. junit3 vs junit4

121. junit4 世代なので､素直
に junit4 つかってます

122. assertThat(actual,
is(expected));

123. 読む分にはいいけど､
書きづらい｡｡

124. assertj を使う

125. assertThat(actual)
.isEqualTo(expected)

126. 補完が効きやすい
= IDE Friendly

127. assertThat(list)
.hasSize(5)

128. 開発が活発

129. assertThat(uri)
.hasPath(“/“)
.hasPort(80);

130. 先週ぐらいに要望だし
たら､だれか実装してた｡

131. ところで､､

132. Google truth ってどう
なの?

133. dagger2 とか､google 発
プロダクトで利用されてる

134. だいたい assertj
と一緒

135. コードが小難しい
assertj のほうが好き

136. まとめ
• assertj 便利｡

137. Continuous Integration

139. 全体の構成

140. gh:e jenkins
エン
ジニア
Nexus
Enterprise
Deploy
System
ServerServer Server Server

141. Nexus Enterprise へは
jenkins からしか上がらない

142. テスト通らないコード
はリリースできない

143. CI は誰かがお膳立てして
あげればみんな諦めて使う

144. Findbugs checkstyle

145. gh:e から p-r 投げたら
テストが自動で回る

146. CI ないと､テストは
ぶっ壊れる

147. CI 回さないと
自分の書いたコードを
誰かが壊す

148. CI は基本｡

149. 僕のやり方まとめ
• DB のテストは実際に DB を使う
• 外部 API のテストは実際に API をコールする
• コントローラのテストはサーブレットコンテナ
を起動する
• CI を常に回す

150. おしまい
• (CENSORED)

151. 以上｡