Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カジュアルなテスト&仕様書としてJSON+node requestのご提案
Search
Minoru KAWAMOTO
May 25, 2015
Programming
1
2.8k
カジュアルなテスト&仕様書として JSON+node requestのご提案
Testing Casual Talks #2 LTの資料です
Minoru KAWAMOTO
May 25, 2015
Tweet
Share
More Decks by Minoru KAWAMOTO
See All by Minoru KAWAMOTO
メディカルノート開発/インフラのあゆみ
k12u
0
1.6k
Other Decks in Programming
See All in Programming
Front-end application development, Symfony-style(s)
dunglas
2
1.9k
エンターテイメント業界で利用されるAWS
demuyan
0
200
Zero Waste, Radical Magic, and Italian Graft – Quarkus Efficiency Secrets
hollycummins
0
220
ADRを一年運用してみた/adr_after_a_year
hanhan1978
7
2.2k
Ruby Pattern Matching
bkuhlmann
0
920
オブジェクト指向のリ・オリエンテーション~歴史を振り返り、AI時代に向きなおる~
hanyudaeiiti
10
5.6k
try! Swift Tokyo 2024のLT枠に採択されたプロポーザルを出すときに考えていたこと
ski
0
340
CircleCIを活用して AWSへの継続的デリバリーを 実践する
coconala_engineer
1
230
pixivアプリでマルチモジュールを実現するまで
gatosyocora
1
130
From Spring Boot 2 to Spring Boot 3 with Java 21 and Jakarta EE
ivargrimstad
0
1.1k
二郎系ラーメンのコールで学ぶ AST 解析
memory1994
PRO
7
1.7k
スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた / Re-reading the Sprint Retrospective Section in the Scrum Guide
mackey0225
3
330
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
242
12k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.1k
Happy Clients
brianwarren
91
6.4k
How STYLIGHT went responsive
nonsquared
92
4.8k
Code Review Best Practice
trishagee
54
15k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Optimizing for Happiness
mojombo
370
69k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
29
6k
Fireside Chat
paigeccino
20
2.6k
How to Ace a Technical Interview
jacobian
272
22k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
Transcript
カジュアルなテスト&仕様書として 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サイトとか準備中でまだ存在しませ んが怪しいものではございません