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
3.1k
カジュアルなテスト&仕様書として 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.8k
Other Decks in Programming
See All in Programming
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
1k
Workers を定期実行する方法は一つじゃない
rokuosan
0
130
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
17
6.1k
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.4k
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
34
10k
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
4
710
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
470
0から始めるモジュラーモノリス-クリーンなモノリスを目指して
sushi0120
0
170
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
0
540
新しいモバイルアプリ勉強会(仮)について
uetyo
1
190
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
370
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
150
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
For a Future-Friendly Web
brad_frost
179
9.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Docker and Python
trallard
45
3.5k
It's Worth the Effort
3n
185
28k
Code Reviewing Like a Champion
maltzj
524
40k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
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サイトとか準備中でまだ存在しませ んが怪しいものではございません