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
unittest
Search
tsuyoshi nakamura
August 31, 2016
Technology
0
61
unittest
unit testをちゃんとした話
tsuyoshi nakamura
August 31, 2016
Tweet
Share
More Decks by tsuyoshi nakamura
See All by tsuyoshi nakamura
社内の勉強会で発表した_output_一部抜粋版_.pdf
tsuyoshi
0
430
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
49
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
1.8k
PHPを少し深堀るよ.pdf
tsuyoshi
0
310
Reactive_Manifesto.pdf
tsuyoshi
0
42
About_Resilience.pdf
tsuyoshi
1
60
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
1.2k
スタートアップしてからの失敗の数々
tsuyoshi
0
2.3k
スタートアップエンジニアの役割
tsuyoshi
0
470
Other Decks in Technology
See All in Technology
Bounded Context: Problem or Solution?
ewolff
1
200
Platform Engineeringは自由のめまい
nwiizo
1
500
Culture Deck
optfit
0
190
Ask! NIKKEIの運用基盤と改善に向けた取り組み / NIKKEI TECH TALK #30
kaitomajima
1
420
ゆもつよがこの30年間自ら経験してきたQA、テストの歴史と未来
ymty
4
670
10分で紹介するAmazon Bedrock利用時のセキュリティ対策 / 10-minutes introduction to security measures when using Amazon Bedrock
hideakiaoyagi
0
150
モノレポ開発のエラー、誰が見る?Datadog で実現する適切なトリアージとエスカレーション
biwashi
5
730
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
180
AndroidデバイスにFTPサーバを建立する
e10dokup
0
210
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
1
180
ろう・難聴者のコミュニケーションを円滑化する取り組み
chiemi627
0
130
The 5 Obstacles to High-Performing Teams
mdalmijn
0
250
Featured
See All Featured
BBQ
matthewcrist
86
9.4k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Navigating Team Friction
lara
183
15k
Side Projects
sachag
452
42k
Facilitating Awesome Meetings
lara
51
6.2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
4 Signs Your Business is Dying
shpigford
182
22k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
The Cult of Friendly URLs
andyhume
78
6.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Transcript
テストコードをちゃんとした話 中村剛 09/01 2015
アジェンダ ①なぜテストコードが書けていなかったのか反省と分析 ②現状を踏まえどうやって変えていったか ③まとめ
①:忙しさという名の響きに負けた 全くのゼロからのスタートアップでやるべき事が溢れ、後 回しになり結局、十分な時間が取れなかった フレームワークの比較見当、コーディング規約、テスト方 針、すべてが後手になり統一意識が取れず、各々が考え る実装でくみ上げられていった。
・同じようなメソッドが無駄に増える ・デグレが多発 ・単純な凡ミスが増加 ・ブラウザので手動テスト頼み、コストがドンドン膨らむ この時テストコードの存在すらないので当然カバレッジ0% よくあるダメなパターン
②:決めを作ってとにかく頑張る フレームワークの特性に合わせてある程度のコーディン グ規約を決めた。 頑張ってリファクタした。 Jenkinsでユニットテストを定期的に実施するようにした Jenkinsでテストの結果、カバレッジを視覚化した Githubに移行してレビュー行程を導入した
②:頑張った結果新たな問題も ビジネスサイドからすると、エンジニアは頑張ってコード書 いてるけど、別に新機能や改善されてる機能のリリースが 少ないという不満 抱えている問題、先送りすればするほど傷が深くなるので 今その問題に対応してる為、新機能開発が遅れている旨 を説明 といってもリファクタ+テストコードの実装だけでずっと人 員を避けないので、新規機能も実装+ボーイスカウトポリ シー(通りかかった道のゴミを拾うポリシー)で実装を進め
た
大きな声で言えないけど軽く無視してやり続けた。 (時として必要) 100%のカバレッジは果てしなく遠いゴールなので70〜80% した。Webサービスとして適正値と判断
③:まとめ ・いくら時間が無くとも頑張りどころはあって、ココで踏ん張 りきれずに妥協すると向こう2年をこの問題に悩まされる と考えて頑張る ・色々考えて決めたら、途中問題が出てきても頑張りきる ただし、結果間違った決めだった可能性もあるので時に 真摯に振返る ・自動化できる部分やツールで軽減できる事、定量的に見 える化は積極的に活用する