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
Ryo Yoneyama
March 18, 2016
Programming
3
950
テストコード文化を創る
サービス立ち上げから約2年間のテストコード (RSpec) の変遷
Ryo Yoneyama
March 18, 2016
Tweet
Share
More Decks by Ryo Yoneyama
See All by Ryo Yoneyama
Web系エンジニア職とWebを支える技術の紹介
yulii
0
210
ゼロから始める IntercomでCS立ち上げ
yulii
4
1.6k
エンジニアになるきっかけとエンジニアとしてのプライド / Career Anchors (2016-08-17)
yulii
0
350
男子(おじさん)が創る女性向けサービスのデプロイ戦略
yulii
5
1k
キャリア戦略論
yulii
2
1.3k
LiBz CAREER の作り方
yulii
1
280
1 → 10 を創る開発基盤
yulii
0
8.1k
Emoji Communication
yulii
0
250
短納期&少人数でも 実現できるCI
yulii
2
6.8k
Other Decks in Programming
See All in Programming
Namespace and Its Future
tagomoris
6
670
[FEConf 2025] 모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년
mmmaxkim
0
1.4k
testingを眺める
matumoto
1
130
パッケージ設計の黒魔術/Kyoto.go#63
lufia
3
390
速いWebフレームワークを作る
yusukebe
3
740
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
270
AIエージェント開発、DevOps and LLMOps
ymd65536
1
370
AIレビュアーをスケールさせるには / Scaling AI Reviewers
technuma
2
230
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
280
Langfuseと歩む生成AI活用推進
licux
3
320
実用的なGOCACHEPROG実装をするために / golang.tokyo #40
mazrean
1
120
Rancher と Terraform
fufuhu
2
170
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Rails Girls Zürich Keynote
gr2m
95
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
GitHub's CSS Performance
jonrohan
1032
460k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Optimizing for Happiness
mojombo
379
70k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Why Our Code Smells
bkeepers
PRO
339
57k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
570
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 でコード品質の劣化を防ぐ
ビジネスにコードをフィットさせよう