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

Testing Casual Talks #2 LTの資料です

Transcript

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