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
920
テストコード文化を創る
サービス立ち上げから約2年間のテストコード (RSpec) の変遷
Ryo Yoneyama
March 18, 2016
Tweet
Share
More Decks by Ryo Yoneyama
See All by Ryo Yoneyama
Web系エンジニア職とWebを支える技術の紹介
yulii
0
170
ゼロから始める IntercomでCS立ち上げ
yulii
4
1.5k
エンジニアになるきっかけとエンジニアとしてのプライド / Career Anchors (2016-08-17)
yulii
0
330
男子(おじさん)が創る女性向けサービスのデプロイ戦略
yulii
5
980
キャリア戦略論
yulii
2
1.2k
LiBz CAREER の作り方
yulii
1
260
1 → 10 を創る開発基盤
yulii
0
8k
Emoji Communication
yulii
0
220
短納期&少人数でも 実現できるCI
yulii
2
6.7k
Other Decks in Programming
See All in Programming
WebDriver BiDiとは何なのか
yotahada3
1
140
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
320
最近のVS Codeで気になるニュース 2025/01
74th
1
260
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
120
Introduction to kotlinx.rpc
arawn
0
670
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
120
富山発の個人開発サービスで日本中の学校の業務を改善した話
krpk1900
4
380
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
950
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
45
16k
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
9
1.8k
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
170
SwiftUI Viewの責務分離
elmetal
PRO
1
220
Featured
See All Featured
Raft: Consensus for Rubyists
vanstee
137
6.8k
KATA
mclloyd
29
14k
Thoughts on Productivity
jonyablonski
69
4.5k
Navigating Team Friction
lara
183
15k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
For a Future-Friendly Web
brad_frost
176
9.5k
Embracing the Ebb and Flow
colly
84
4.6k
A Philosophy of Restraint
colly
203
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
99
18k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
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 でコード品質の劣化を防ぐ
ビジネスにコードをフィットさせよう