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
テストコード文化を創る
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Ryo Yoneyama
March 18, 2016
Programming
980
3
Share
テストコード文化を創る
サービス立ち上げから約2年間のテストコード (RSpec) の変遷
Ryo Yoneyama
March 18, 2016
More Decks by Ryo Yoneyama
See All by Ryo Yoneyama
Web系エンジニア職とWebを支える技術の紹介
yulii
0
230
ゼロから始める IntercomでCS立ち上げ
yulii
4
1.7k
エンジニアになるきっかけとエンジニアとしてのプライド / Career Anchors (2016-08-17)
yulii
0
390
男子(おじさん)が創る女性向けサービスのデプロイ戦略
yulii
5
1.1k
キャリア戦略論
yulii
2
1.3k
LiBz CAREER の作り方
yulii
1
310
1 → 10 を創る開発基盤
yulii
0
8.1k
Emoji Communication
yulii
0
280
短納期&少人数でも 実現できるCI
yulii
2
6.8k
Other Decks in Programming
See All in Programming
Codex CLI でつくる、Issue から merge までの開発フロー
amata1219
0
330
我々はなぜ「層」を分けるのか〜「関心の分離」と「抽象化」で手に入れる変更に強いシンプルな設計〜 #phperkaigi / PHPerKaigi 2026
shogogg
2
830
AI活用のコスパを最大化する方法
ochtum
0
380
3分でわかるatama plusのQA/about atama plus QA
atamaplus
0
120
メッセージングを利用して時間的結合を分離しよう #phperkaigi
kajitack
3
560
Coding at the Speed of Thought: The New Era of Symfony Docker
dunglas
0
4.7k
Everything Claude Code OSS詳細 — 5層構造の中身と導入方法
targe
0
160
それはエンジニアリングの糧である:AI開発のためにAIのOSSを開発する現場より / It serves as fuel for engineering: insights from the field of developing open-source AI for AI development.
nrslib
1
830
感情を設計する
ichimichi
5
1.3k
Offline should be the norm: building local-first apps with CRDTs & Kotlin Multiplatform
renaudmathieu
0
150
Laravel Nightwatchの裏側 - Laravel公式Observabilityツールを支える設計と実装
avosalmon
1
320
Coding as Prompting Since 2025
ragingwind
0
770
Featured
See All Featured
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
190
WCS-LA-2024
lcolladotor
0
520
Faster Mobile Websites
deanohume
310
31k
Un-Boring Meetings
codingconduct
0
260
How Software Deployment tools have changed in the past 20 years
geshan
0
33k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
210
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.6k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.8k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
160
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Transcript
テストコード文化を創る Ryo Yoneyama LiB, Inc.
“Geek Suit” Ryo Yoneyama 株式会社LiB(リブ)
None
なぜ、プログラミングはつらいのか?
プログラミングの悲しい事実 - コードを書いた分だけバグが出る - コードは触らないと腐っていく - 今は素晴らしいコードもいつか邪魔になる - 仕様変更は簡単だけど、同じ手軽さでコードは変わらない
テストを書いても変わらない悲しい事実 - テストを書いてもバグは出る - テストが書いてあってもコードは腐敗していく - テストが書いてあっても、素晴らしいコードを維持できるわけではない - テストがあっても仕様変更に伴うコードの改修は容易じゃない
テストはモニタリング手法であり、 コードの品質は設計と実装が決める
あなたは、なぜテストを書かないのか? - テストを書く時間がない - 実装コードがダメだから、テストが書けない(書きづらい) - まだ仕様が曖昧だからテストが書けない - テストを書くより実装の方が楽しい -
ちゃんと動いてるから良くね?
なぜ、テストを書くのか?
ビジネスが変わればコードも変わる ↓ 終わらないリファクタリングの始まり
『リファクタリング』を 支えるテストを書こう
LiBzCAREER の変遷
Phase 1 : 初期ローンチ Phase 2 : ひとりで開発 Phase 3
: チームで開発
初期ローンチ ; rake stats
俺が書いたコードが 正しく動いているはずがない! けど、テストを書く時間がない
Not RSpec but factory_girl
! ランダムにデータ生成 ! !
正しいデータを ランダムに大量生成して ポチポチと手動テスト 一部Spec はありますが、 メインは手動テストでした・・・
[WARNING] たまにfail するテスト 放置すると テストがfail することに慣れてしまうので注意!
ひとりで開発 ; rake stats
Controllers Views Models Routes
Controller でrender_views を使う !
Controller を叩けば 少ないコードで 広い範囲のコードが動く
そのテストコードは正しいのか? - そもそもテスト駆動じゃない - ユニットテストじゃない - render_views しているのでテストの実効速度は遅い - 間接的にModel
やView も動くがテストケースを網羅しているわけじゃない
コードの品質モニタリングのために テストを書いている。 細かいことは置いといて、 ある程度デグレに気づけたらOK! (ドヤッ
[WARNING] 実装変更に弱いテストコード - いろんなコードに依存してるため、ちょっと変えるとテストが落ちまくる - 実装コードがダメだから、テストコードの依存関係を取り除けない そのテストコード捨てましょう! テストがなくても、サービスは動きます。
チームで開発 ; rake stats
Model のSpec を継ぎ足しながら、 テストの独立性を高めてます・・・ 紆余曲折あったけど、 『テストコードはあるのが当たり前』ということが チームの共通認識になったのは良かったかと。
RuboCop やBrakeman でコード品質の劣化を防ぐ
ビジネスにコードをフィットさせよう