Share
Embed
Slide 1
Slide 1 text
カジュアルなテスト&仕様書として
JSON+node requestのご提案
Testing Casual Talks #2
@k12u
(kawamoto.minoru)
Slide 2
Slide 2 text
アカウントが取れることに定評ある
k12u@twitter
k12u@github
k12u@なんでも
Slide 3
Slide 3 text
成分
フリーランス:3 会社員:7
マネージメント:4 開発:6 QA:0
サーバサイド:5 インフラ:4 フロント:1
Slide 4
Slide 4 text
とある仕事での話
● APIサーバを作る仕事
● テスト書きたいけど予算・工数の都合が…
● 正直めんどい
● (諸事情により)費用対効果見込めない
※今は外注っぽい仕事はしてません
Slide 5
Slide 5 text
面倒でもやらなきゃいけない仕事
● 仕様書
● フロントエンドとの連携
○ 外部仕様作りながらAPI決めながら開発
Slide 6
Slide 6 text
どうせなら全部一緒にやっちゃおう
● テストコード書くの正直面倒ですよね？
○ 怒らないから言ってごらん
Slide 7
Slide 7 text
テストランナーの仕様
JSON APIの応答をどこかでみたようなルールで
チェックする
仕様もJSON(※)で書く
(※)nodeのrequestモジュールの仕様で
Slide 8
Slide 8 text
テストランナーの仕様
001-hogehoge.json 〜 999-hogehoge.json
を順番に流して動作確認
001:
{request: {[json]}, response: {[json]}
999:
{request: {[json]}, response: {[json]}
Slide 9
Slide 9 text
テストランナーの仕様
fixture: なし
割り切り設計&全体の一貫性重視
Slide 10
Slide 10 text
テストランナーの仕様
● evalBeforeRequest
● evalAfterResponse
リクエスト/レスポンスの中身でテストしにくい部分
(変数の代入、現在時刻等)をJSのコードで管理す
る。
汚い部分はここに追い出される
Slide 11
Slide 11 text
考えたけど今回はボツにした
JSON Schemaでvalidationするといいかも？
X ルールが必要十分なのを保証できない
X 怠けるためのはずが書くのが微妙に大変
Slide 12
Slide 12 text
使い道
● 開発時
○ PR: [wip] ○○機能仕様
○ Issue: [Bug]このレスポンスがおかしい
● 仕様書として
● 実装/仕様/仕様書の不備がCIでfailする喜び
Slide 13
Slide 13 text
振り返り:どうしてこれをやっているのか
Web開発の気持ち
● Viewは頻繁に変わるからロジックをテストしよう
○ 単体テスト中心が自然
API開発が普通になると
● Viewが仕様
○ 仕様の変更にテストが追随するのも自然
○ APIの外部仕様のテストが自然と中心に
Slide 14
Slide 14 text
振り返り：思わぬ副作用
「テスト書きすぎ問題」が起きにくい
(外部仕様に対するテストしかないから)
Slide 15
Slide 15 text
振り返り:TIPS
ファイル名の変更が多すぎると
レビューがつらい
001.json → 00100.json
ぐらいでちょうどいいのかも
Slide 16
Slide 16 text
振り返り
軽い気持ちでやってみたら意外とよかった
カジュアルな開発にはもう単体テストとかあまりい
らないかも
※書いた方がよさそうなときには書く程度
Slide 17
Slide 17 text
関連
WebAPIリクエスト仕様書としてcurlコマンドのご提案
http://qiita.com/Hiraku/items/dfda2f8a5353b0742271
を見て題名を変えました
Slide 18
Slide 18 text
ありがとうございました
お問い合わせはいろんなサイトの@k12uまで
(お知らせ)
お仕事あります。※していただくほう
会社とかWebサイトとか準備中でまだ存在しませ
んが怪しいものではございません