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
58
unittest
unit testをちゃんとした話
tsuyoshi nakamura
August 31, 2016
Tweet
Share
More Decks by tsuyoshi nakamura
See All by tsuyoshi nakamura
社内の勉強会で発表した_output_一部抜粋版_.pdf
tsuyoshi
0
400
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
39
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
1.7k
PHPを少し深堀るよ.pdf
tsuyoshi
0
280
Reactive_Manifesto.pdf
tsuyoshi
0
36
About_Resilience.pdf
tsuyoshi
1
55
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
1.1k
スタートアップしてからの失敗の数々
tsuyoshi
0
2.2k
スタートアップエンジニアの役割
tsuyoshi
0
440
Other Decks in Technology
See All in Technology
成長期に歩みを止めないための創業期の開発文化形成
mayah
6
420
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
480
フルリモートワークはエンジニアの夢を叶えたか? #cm_odyssey
mamohacy
2
600
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
280
[NIKKEI Tech Talk]Bias for Action!! 実践から学ぶための仕組とコミュニティ / Community for Practice and Learning
kanamasa
0
280
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.8k
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
220
データ分析を支える技術 生成AI再入門
ishikawa_satoru
0
380
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
Featured
See All Featured
Side Projects
sachag
451
42k
A Tale of Four Properties
chriscoyier
155
22k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
RailsConf 2023
tenderlove
16
720
The World Runs on Bad Software
bkeepers
PRO
63
11k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
5 minutes of I Can Smell Your CMS
philhawksworth
200
19k
Become a Pro
speakerdeck
PRO
15
4.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Creatively Recalculating Your Daily Design Routine
revolveconf
214
11k
The Brand Is Dead. Long Live the Brand.
mthomps
52
36k
Transcript
テストコードをちゃんとした話 中村剛 09/01 2015
アジェンダ ①なぜテストコードが書けていなかったのか反省と分析 ②現状を踏まえどうやって変えていったか ③まとめ
①:忙しさという名の響きに負けた 全くのゼロからのスタートアップでやるべき事が溢れ、後 回しになり結局、十分な時間が取れなかった フレームワークの比較見当、コーディング規約、テスト方 針、すべてが後手になり統一意識が取れず、各々が考え る実装でくみ上げられていった。
・同じようなメソッドが無駄に増える ・デグレが多発 ・単純な凡ミスが増加 ・ブラウザので手動テスト頼み、コストがドンドン膨らむ この時テストコードの存在すらないので当然カバレッジ0% よくあるダメなパターン
②:決めを作ってとにかく頑張る フレームワークの特性に合わせてある程度のコーディン グ規約を決めた。 頑張ってリファクタした。 Jenkinsでユニットテストを定期的に実施するようにした Jenkinsでテストの結果、カバレッジを視覚化した Githubに移行してレビュー行程を導入した
②:頑張った結果新たな問題も ビジネスサイドからすると、エンジニアは頑張ってコード書 いてるけど、別に新機能や改善されてる機能のリリースが 少ないという不満 抱えている問題、先送りすればするほど傷が深くなるので 今その問題に対応してる為、新機能開発が遅れている旨 を説明 といってもリファクタ+テストコードの実装だけでずっと人 員を避けないので、新規機能も実装+ボーイスカウトポリ シー(通りかかった道のゴミを拾うポリシー)で実装を進め
た
大きな声で言えないけど軽く無視してやり続けた。 (時として必要) 100%のカバレッジは果てしなく遠いゴールなので70〜80% した。Webサービスとして適正値と判断
③:まとめ ・いくら時間が無くとも頑張りどころはあって、ココで踏ん張 りきれずに妥協すると向こう2年をこの問題に悩まされる と考えて頑張る ・色々考えて決めたら、途中問題が出てきても頑張りきる ただし、結果間違った決めだった可能性もあるので時に 真摯に振返る ・自動化できる部分やツールで軽減できる事、定量的に見 える化は積極的に活用する