Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
テストコード文化を創る
Search
Ryo Yoneyama
March 18, 2016
Programming
3
970
テストコード文化を創る
サービス立ち上げから約2年間のテストコード (RSpec) の変遷
Ryo Yoneyama
March 18, 2016
Tweet
Share
More Decks by Ryo Yoneyama
See All by Ryo Yoneyama
Web系エンジニア職とWebを支える技術の紹介
yulii
0
220
ゼロから始める IntercomでCS立ち上げ
yulii
4
1.6k
エンジニアになるきっかけとエンジニアとしてのプライド / Career Anchors (2016-08-17)
yulii
0
370
男子(おじさん)が創る女性向けサービスのデプロイ戦略
yulii
5
1k
キャリア戦略論
yulii
2
1.3k
LiBz CAREER の作り方
yulii
1
300
1 → 10 を創る開発基盤
yulii
0
8.1k
Emoji Communication
yulii
0
260
短納期&少人数でも 実現できるCI
yulii
2
6.8k
Other Decks in Programming
See All in Programming
モデル駆動設計をやってみようワークショップ開催報告(Modeling Forum2025) / model driven design workshop report
haru860
0
240
非同期処理の迷宮を抜ける: 初学者がつまづく構造的な原因
pd1xx
1
670
WebRTC と Rust と8K 60fps
tnoho
2
1.9k
tsgolintはいかにしてtypescript-goの非公開APIを呼び出しているのか
syumai
5
1.9k
React Native New Architecture 移行実践報告
taminif
1
140
Tinkerbellから学ぶ、Podで DHCPをリッスンする手法
tomokon
0
110
【Streamlit x Snowflake】データ基盤からアプリ開発・AI活用まで、すべてをSnowflake内で実現
ayumu_yamaguchi
1
110
手軽に積ん読を増やすには?/読みたい本と付き合うには?
o0h
PRO
1
160
tparseでgo testの出力を見やすくする
utgwkk
1
160
複数人でのCLI/Infrastructure as Codeの暮らしを良くする
shmokmt
5
2.2k
認証・認可の基本を学ぼう前編
kouyuume
0
190
ソフトウェア設計の課題・原則・実践技法
masuda220
PRO
26
22k
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.6k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Done Done
chrislema
186
16k
Bash Introduction
62gerente
615
210k
Navigating Team Friction
lara
191
16k
Being A Developer After 40
akosma
91
590k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
196
69k
How GitHub (no longer) Works
holman
316
140k
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 でコード品質の劣化を防ぐ
ビジネスにコードをフィットさせよう