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
900
テストコード文化を創る
サービス立ち上げから約2年間のテストコード (RSpec) の変遷
Ryo Yoneyama
March 18, 2016
Tweet
Share
More Decks by Ryo Yoneyama
See All by Ryo Yoneyama
Web系エンジニア職とWebを支える技術の紹介
yulii
0
160
ゼロから始める IntercomでCS立ち上げ
yulii
4
1.5k
エンジニアになるきっかけとエンジニアとしてのプライド / Career Anchors (2016-08-17)
yulii
0
320
男子(おじさん)が創る女性向けサービスのデプロイ戦略
yulii
5
960
キャリア戦略論
yulii
2
1.2k
LiBz CAREER の作り方
yulii
1
250
1 → 10 を創る開発基盤
yulii
0
8k
Emoji Communication
yulii
0
220
短納期&少人数でも 実現できるCI
yulii
2
6.7k
Other Decks in Programming
See All in Programming
C++でシェーダを書く
fadis
6
3.9k
みんなでプロポーザルを書いてみた
yuriko1211
0
190
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
phigasui
3
2.3k
Quine, Polyglot, 良いコード
qnighy
4
620
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
160
シールドクラスをはじめよう / Getting Started with Sealed Classes
mackey0225
3
430
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
4
2.8k
受け取る人から提供する人になるということ
little_rubyist
0
180
弊社の「意識チョット低いアーキテクチャ」10選
texmeijin
5
24k
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
500
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
170
推し活としてのrails new/oshikatsu_ha_iizo
sakahukamaki
3
2k
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
222
8.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Typedesign – Prime Four
hannesfritz
40
2.4k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Why Our Code Smells
bkeepers
PRO
334
57k
Side Projects
sachag
452
42k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9k
Fireside Chat
paigeccino
33
3k
The Cost Of JavaScript in 2023
addyosmani
45
6.7k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
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 でコード品質の劣化を防ぐ
ビジネスにコードをフィットさせよう