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
Java 质量保障
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
LI Daobing
August 04, 2011
Programming
290
3
Share
Java 质量保障
LI Daobing
August 04, 2011
More Decks by LI Daobing
See All by LI Daobing
How to attack TLS in PQC decade, part I
lidaobing
0
40
出了问题不要靠猜
lidaobing
40
4k
HTTP协议相关的若干安全问题
lidaobing
9
1.2k
Debian & Packaging
lidaobing
1
560
OAuth: How and Why?
lidaobing
1
150
从 Struts 迁移到 Spring MVC,以及为什么?
lidaobing
2
660
glusterfs 文件系统
lidaobing
2
190
如何学习 Shell
lidaobing
3
330
Other Decks in Programming
See All in Programming
Road to RubyKaigi: Play Hard(ware)
makicamel
1
540
ハーネスエンジニアリングにどう向き合うか 〜ルールファイルを超えて開発プロセスを設計する〜 / How to approach harness engineering
rkaga
27
19k
決定論 vs 確率論:Gemini 3 FlashとTF-IDFを組み合わせた「法規判定エンジン」の構築
shukob
0
150
[RubyKaigi 2026] Require Hooks
palkan
1
290
20260514 - build with ai 2026 - build LINE Bot with Gemini CLI
line_developers_tw
PRO
0
190
PHPer、Cloudflare に引っ越す
suguruooki
1
140
PHPでバイナリをパースして理解するASN.1
muno92
PRO
0
410
ハーネスエンジニアリングとは?
kinopeee
13
6.8k
JOAI2026 1st solution - heron0519 -
heron0519
0
180
My daily life on Ruby
a_matsuda
3
180
実践ハーネスエンジニアリング:ステアリングループを実例から読み解く / Practical Harness Engineering: Understanding Steering Loops Through Real-World Examples
nrslib
4
3.1k
Lightning-Fast Method Calls with Ruby 4.1 ZJIT / RubyKaigi 2026
k0kubun
3
2.5k
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.8k
Automating Front-end Workflow
addyosmani
1370
200k
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
1
530
The Curious Case for Waylosing
cassininazir
0
340
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Raft: Consensus for Rubyists
vanstee
141
7.4k
Claude Code のすすめ
schroneko
67
220k
WCS-LA-2024
lcolladotor
0
570
GitHub's CSS Performance
jonrohan
1032
470k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
190
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Transcript
Java 质量保障 LI Daobing <
[email protected]
> 2011-08-04
Outline 如何做单元测试 如何让代码对单元测试友好 一种中规中矩的结构设计 总结
注意 : 以下都是个人观点
单元测试 单元测试的目的 验证类实现了设计时承诺的行为 帮助再现 bug 帮助发现
bug 保障重构
单元测试的基本约定 使用 JUnit4 或者 TestNG 源码与测试的包 (package) 名保持一致,
FooService 对应的测试类为 FooServiceTest
测试名最好是一个句子 测试名最好是一个句子 好的名字 : runShouldRaiseFooExceptionWithNullArgumen t 一般的名字
: testRun 糟糕的名字 : test2 最好的情况是看见一个测试类的全部方法名就知 道这个类能干什么,什么情况下会有什么行为
为测试准备单独的环境 可以用 System.getenv 或者 System.getProperty 来判定当前的环境 为测试准备一份单独的配置文件 /
工厂类 /Spring Configuration
使用依赖注入来简化测试
使用 protected 函数来 mock 底 层依赖
如何正确测试异常
其他要点 测试不易过大,每个单元测试尽量只检测类的一 个特性 测试不仅仅是执行代码,更要检测代码执行后结 果是否满足期望 不要在单元测试中随意 catch
异常,尽量让异 常抛出来 如果使用 Spring, 可以使用 Spring 现有的测试 支持
Outline 如何做单元测试 如何让代码对单元测试友好 一种中规中矩的包设计 总结
服务应当是一个对象而不是一个类 测试需要构建一个测试用对象,依赖于一些 mock 的底层服务 甚至需要创建多个服务 这个时候使用对象比使用类方便
对象意味着晚绑定 , 晚绑定意味着灵活
服务应当是一个对象而不是一个类 比如 A 服务依赖于 B 服务,如果 B 服务是一 个对象,那么可以构造出一个
B 服务的 Mock 对象,注入到 A 服务,方便测试 A 服务 如果 B 服务是一个类,那么测试起来就会很麻 烦
服务的依赖尽量在构造时一次传入 在服务创建时可以一次检查所有可能的问题 避免服务处于一个无效的状态
使用工厂简化服务构造
按 package 划分 Factory 如果工程比较大,只用一个 Factory 类会显得 过于复杂,一般建议按 package
来划分 Factory 同时一个 package 最好只有一个 Factory, Factory 具有配置的隐喻,而配置应该集中而不 是分散 比如 com.snda.llap.replicator.client.DatanodeChoos erClientFactory
你其实也可以使用 Spring
声明方法时不要使用通用异常类
不要拦截你不知道如何处理的异常
在边界处检查异常 尽量在系统边界处检查异常,而在系统中间让异 常透明通过 比如 web 或者 socket 服务,只在相应前做一
个通用异常检查,并返回信息给用户 当然在另外一个边界处也要做适当检查,避免所 依赖的其他服务出现异常时延迟发现。
不要使用 e.printStackTrace()
组织你的异常类 Exception KeybaseException FooException RuntimeException
KeybaseRuntimeException BarException
其他建议 熟悉 commons-lang,codec,io, ... 库 熟悉 guava 库
一种中规中矩的工程结构
Summary Java 静态,面向对象 安全,易用,对多线程支持较好 推崇单元测试,文档,代码检查。
推崇设计模式,重构,团队合作。 也是在企业应用领域使用最广泛的语言。 不是动态语言 (Python, Ruby, …) 对高并发支持不好 (Scala, ...)
None
Q&A
Thanks for your attention