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
イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code
nrslib
1
420
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
20
3.6k
Gleamという選択肢
comamoca
6
760
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
1.1k
GoのGenericsによるslice操作との付き合い方
syumai
3
690
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
370
Create a website using Spatial Web
akkeylab
0
300
ReadMoreTextView
fornewid
1
480
技術同人誌をMCP Serverにしてみた
74th
1
370
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
410
Kotlin エンジニアへ送る:Swift 案件に参加させられる日に備えて~似てるけど色々違う Swift の仕様 / from Kotlin to Swift
lovee
1
260
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
580
Featured
See All Featured
The Language of Interfaces
destraynor
158
25k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
How STYLIGHT went responsive
nonsquared
100
5.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
4 Signs Your Business is Dying
shpigford
184
22k
Producing Creativity
orderedlist
PRO
346
40k
We Have a Design System, Now What?
morganepeng
53
7.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Optimizing for Happiness
mojombo
379
70k
How GitHub (no longer) Works
holman
314
140k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
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サイトとか準備中でまだ存在しませ んが怪しいものではございません