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
63
unittest
unit testをちゃんとした話
tsuyoshi nakamura
August 31, 2016
Tweet
Share
More Decks by tsuyoshi nakamura
See All by tsuyoshi nakamura
社内の勉強会で発表した_output_一部抜粋版_.pdf
tsuyoshi
0
460
PHPを少しでも早く_条件はあるよ_.pdf
tsuyoshi
0
69
スタートアップ6年目のレビュー文化.pdf
tsuyoshi
1
1.9k
PHPを少し深堀るよ.pdf
tsuyoshi
0
350
Reactive_Manifesto.pdf
tsuyoshi
0
60
About_Resilience.pdf
tsuyoshi
1
72
エンジニアの循環ってgood_or_bad_.pdf
tsuyoshi
0
1.2k
スタートアップしてからの失敗の数々
tsuyoshi
0
2.4k
スタートアップエンジニアの役割
tsuyoshi
0
510
Other Decks in Technology
See All in Technology
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.7k
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.3k
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
510
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
30k
Flutterでキャッチしないエラーはどこに行く
taiju59
0
220
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
170
La gouvernance territoriale des données grâce à la plateforme Terreze
bluehats
0
120
AI駆動開発に向けた新しいエンジニアマインドセット
kazue
0
260
なぜSaaSがMCPサーバーをサービス提供するのか?
sansantech
PRO
8
2.5k
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
2
430
5年目から始める Vue3 サイト改善 #frontendo
tacck
PRO
3
200
[RSJ25] Feasible RAG: Hierarchical Multimodal Retrieval with Feasibility-Aware Embodied Memory for Mobile Manipulation
keio_smilab
PRO
0
120
Featured
See All Featured
Speed Design
sergeychernyshev
32
1.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Building an army of robots
kneath
306
46k
Unsuck your backbone
ammeep
671
58k
Being A Developer After 40
akosma
90
590k
Statistics for Hackers
jakevdp
799
220k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
GitHub's CSS Performance
jonrohan
1032
460k
Done Done
chrislema
185
16k
Transcript
テストコードをちゃんとした話 中村剛 09/01 2015
アジェンダ ①なぜテストコードが書けていなかったのか反省と分析 ②現状を踏まえどうやって変えていったか ③まとめ
①:忙しさという名の響きに負けた 全くのゼロからのスタートアップでやるべき事が溢れ、後 回しになり結局、十分な時間が取れなかった フレームワークの比較見当、コーディング規約、テスト方 針、すべてが後手になり統一意識が取れず、各々が考え る実装でくみ上げられていった。
・同じようなメソッドが無駄に増える ・デグレが多発 ・単純な凡ミスが増加 ・ブラウザので手動テスト頼み、コストがドンドン膨らむ この時テストコードの存在すらないので当然カバレッジ0% よくあるダメなパターン
②:決めを作ってとにかく頑張る フレームワークの特性に合わせてある程度のコーディン グ規約を決めた。 頑張ってリファクタした。 Jenkinsでユニットテストを定期的に実施するようにした Jenkinsでテストの結果、カバレッジを視覚化した Githubに移行してレビュー行程を導入した
②:頑張った結果新たな問題も ビジネスサイドからすると、エンジニアは頑張ってコード書 いてるけど、別に新機能や改善されてる機能のリリースが 少ないという不満 抱えている問題、先送りすればするほど傷が深くなるので 今その問題に対応してる為、新機能開発が遅れている旨 を説明 といってもリファクタ+テストコードの実装だけでずっと人 員を避けないので、新規機能も実装+ボーイスカウトポリ シー(通りかかった道のゴミを拾うポリシー)で実装を進め
た
大きな声で言えないけど軽く無視してやり続けた。 (時として必要) 100%のカバレッジは果てしなく遠いゴールなので70〜80% した。Webサービスとして適正値と判断
③:まとめ ・いくら時間が無くとも頑張りどころはあって、ココで踏ん張 りきれずに妥協すると向こう2年をこの問題に悩まされる と考えて頑張る ・色々考えて決めたら、途中問題が出てきても頑張りきる ただし、結果間違った決めだった可能性もあるので時に 真摯に振返る ・自動化できる部分やツールで軽減できる事、定量的に見 える化は積極的に活用する