カジュアルなテスト&仕様書として JSON+node requestのご提案

カジュアルなテスト&仕様書として JSON+node requestのご提案 Testing Casual Talks #2 @k12u (kawamoto.minoru)

アカウントが取れることに定評ある k12u@twitter k12u@github k12u@なんでも

成分フリーランス:3 会社員:7 マネージメント:4 開発:6 QA:0 サーバサイド:5 インフラ:4 フロント:1

とある仕事での話 • APIサーバを作る仕事 • テスト書きたいけど予算・工数の都合が… • 正直めんどい • (諸事情により)費用対効果見込めない ※今は外注っぽい仕事はしてません

面倒でもやらなきゃいけない仕事 • 仕様書 • フロントエンドとの連携 ◦ 外部仕様作りながらAPI決めながら開発

どうせなら全部一緒にやっちゃおう • テストコード書くの正直面倒ですよね？ ◦ 怒らないから言ってごらん

テストランナーの仕様 JSON APIの応答をどこかでみたようなルールでチェックする仕様もJSON(※)で書く (※)nodeのrequestモジュールの仕様で

テストランナーの仕様 001-hogehoge.json 〜 999-hogehoge.json を順番に流して動作確認 001: {request: {[json]}, response: {[json]}
999: {request: {[json]}, response: {[json]}

テストランナーの仕様 fixture: なし割り切り設計&全体の一貫性重視

テストランナーの仕様 • evalBeforeRequest • evalAfterResponse リクエスト/レスポンスの中身でテストしにくい部分 (変数の代入、現在時刻等)をJSのコードで管理する。汚い部分はここに追い出される

考えたけど今回はボツにした JSON Schemaでvalidationするといいかも？ X ルールが必要十分なのを保証できない X 怠けるためのはずが書くのが微妙に大変

使い道 • 開発時 ◦ PR: [wip] ◦◦機能仕様 ◦ Issue: [Bug]このレスポンスがおかしい
• 仕様書として • 実装/仕様/仕様書の不備がCIでfailする喜び

振り返り:どうしてこれをやっているのか Web開発の気持ち • Viewは頻繁に変わるからロジックをテストしよう ◦ 単体テスト中心が自然 API開発が普通になると • Viewが仕様 ◦
仕様の変更にテストが追随するのも自然 ◦ APIの外部仕様のテストが自然と中心に

振り返り：思わぬ副作用「テスト書きすぎ問題」が起きにくい (外部仕様に対するテストしかないから)

振り返り:TIPS ファイル名の変更が多すぎるとレビューがつらい 001.json → 00100.json ぐらいでちょうどいいのかも

振り返り軽い気持ちでやってみたら意外とよかったカジュアルな開発にはもう単体テストとかあまりいらないかも ※書いた方がよさそうなときには書く程度

関連 WebAPIリクエスト仕様書としてcurlコマンドのご提案 http://qiita.com/Hiraku/items/dfda2f8a5353b0742271 を見て題名を変えました

ありがとうございましたお問い合わせはいろんなサイトの@k12uまで (お知らせ) お仕事あります。※していただくほう会社とかWebサイトとか準備中でまだ存在しませんが怪しいものではございません

Minoru KAWAMOTO