阿⾥Java开发⼿册
⼀、编程规约
三、单元测试
1.【强制】好的单元测试必须遵守 AIR 原则。
说明：单元测试在线上运⾏时，感觉像空⽓（AIR）⼀样并不存在，但在测试质量的保障上，却是⾮常关键的。好的单元测试宏观上来说，具有⾃动化、独⽴性、可重复执⾏的特点。
A：Automatic（⾃动化）
I：Independent（独⽴性）
R：Repeatable（可重复）
补充：junit使⽤
@BeforeClass：修饰的⽅法会在所有⽅法被调⽤前执⾏，且该⽅法时静态的，所以当测试类被加载后就接着运⾏它，⽽且在内存中他只会存在⼀份实例，他⽐较适合加载配置⽂件（针对所有测试，只执⾏⼀
次 ）
@AfterClass：所修饰的⽅法通常⽤来对资源管理，如关闭数据库连接（针对所有测试，只执⾏⼀次 ）
@Before和@After 会在每个测试⽅法前后各执⾏⼀次大专生留学
@Test：测试⽅法，在这⾥可以测试期望异常和超时时间
@Ignore：忽略的测试⽅法
import static org.junit.Asrt.*;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
public class JunitFlowText {
@BeforeClass
public static void tUpBeforeClass() throws Exception {
System.out.println("this ");
}行长助理
@AfterClasswap monternet com
public static void tearDownAfterClass() throws Exception {
System.out.println("this ");
}
@Before
public void tUp() throws Exception {
System.out.println("this ");
}
@After
public void tearDown() throws Exception {
System.out.println("this ");
}
@Test
public void test1() {
System.out.println("this ");
}
@Test
public void test2() {
System.out.println("this ");
}
}
补充：springboot单元测试
@Transactional
2017高考语文试卷
@RunWith(SpringRunner.class)
@SpringBootTest
public class UrDaoTest {
@Autowired
UrDao dao;
@Test
public void lect(){
Ur u =new Ur();
u.tId(1);
List<Map<String, Object>> res = dao.lect(u);
System.out.println(res);
}
}
2.【强制】单元测试应该是全⾃动执⾏的，并且⾮交互式的。
测试⽤例通常是被定期执⾏的，执⾏过程必须完全⾃动化才有意义。输出结果需要⼈⼯检查的测试不是⼀个好的单元测试。单元测试中不准使⽤ System.out 来进⾏⼈⾁验证，必须使⽤ asrt 来验证。
补充：Java异常处理
Error：是程序中⽆法处理的错误，表⽰运⾏应⽤程序中出现了严重的错误。此类错误⼀般表⽰代码运⾏时JVM出现问题。通常有Virtual MachineError（虚拟机运⾏错误）、NoClassDefFoundError（类定义错误）等。⽐如说当jvm耗完可⽤内存时，将出现OutOfMemoryError。此类错误发⽣时，JVM将终⽌线程。⾮代码性错误。因此，当此类错误发⽣时，应⽤不应该去处理此类错误。
incread
Exception：：程序本⾝可以捕获并且可以处理的异常。
运⾏时异常(不受检异常)：RuntimeException类极其⼦类表⽰JVM在运⾏期间可能出现的错误。编译器不会检查此类异常，并且不要求处理异常，⽐如⽤空值对象的引⽤（NullPointerException）、数组下标越界（ArrayIndexOutBoundException）。此类异常属于不可查异常，⼀般是由程序逻辑错误引起的，在程序中可以选择捕获处理，也可以不处理。
⾮运⾏时异常(受检异常)：Exception中除RuntimeException极其⼦类之外的异常。编译器会检查此类异常，如果程序中出现此类异常，⽐如说IOException，必须对该异常进⾏处理，要么使⽤try-catch捕获，要么使⽤throws语句抛出，否则编译不通过。
public class NotebookNoteFoundExcepotion extends RuntimeException {
private static final long rialVersionUID = 8307029916454948448L;
public NotebookNoteFoundExcepotion() {
super();
}
public NotebookNoteFoundExcepotion(String message, Throwable cau, boolean enableSuppression,
boolean writableStackTrace) {
super(message, cau, enableSuppression, writableStackTrace);
}
public NotebookNoteFoundExcepotion(String message, Throwable cau) {
super(message, cau);
}
public NotebookNoteFoundExcepotion(String message) {
super(message);
}
public NotebookNoteFoundExcepotion(Throwable cau) {
super(cau);
}
}
补充：Java断⾔ asrt
断⾔是java的⼀种语句，它允许对程序提出⼀个判断（假设）。断⾔包含⼀个布尔表达式，在程序运⾏中它应该是真。断⾔⽤于确保程序的正确性，避免逻辑错误 。
import static org.aterThan;
import static org.junit.Asrt.*;
import org.junit.*;
public class AsrtTest {
@Test
public void test1(){
Asrt.asrtTrue("我对了吗",1>5);
mba学习
int[] a =new int[]{1,2,3};
int[] b =new int[]{2,3,4};
Asrt.asrtArrayEquals(a, b);
Asrt.asrtThat("10⼤于5吗?",10,greaterThan(5));
}
}
3.【强制】保持单元测试的独⽴性。
为了保证单元测试稳定可靠且便于维护，单元测试⽤例之间决不能互相调⽤，也不能依赖执⾏的先后次序。
反例：method2 需要依赖 method1 的执⾏，将执⾏结果作为 method2 的输⼊。
4.【强制】单元测试是可以重复执⾏的
不能受到外界环境的影响。
说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执⾏。如果单测对外部环境（⽹络、服务、中间件等）有依赖，容易导致持续集成机制的不可⽤。
正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注⼊，在测试时⽤ spring 这样的 DI框架注⼊⼀个本地（内存）实现或者 Mock 实现。
5.【强制】对于单元测试，要保证测试粒度⾜够⼩
有助于精确定位问题。单测粒度⾄多是类级别，⼀般是⽅法级别。
说明：只有测试粒度⼩才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。
6.【强制】核⼼业务、核⼼应⽤、核⼼模块的增量代码确保单元测试通过。
说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。
bsp
7.【强制】单元测试代码
必须写在如下⼯程⽬录：src/test/java，不允许写在业务代码⽬录下。
说明：源码编译时会跳过此⽬录，⽽单元测试框架默认是扫描此⽬录。
8.【推荐】单元测试的基本⽬标
语句覆盖率达到 70%；核⼼模块的语句覆盖率和分⽀覆盖率都要达到 100%
说明：在⼯程规约的应⽤分层中提到的 DAO 层，Manager 层，可重⽤度⾼的 Service，都应该进⾏单元测试。
9.【推荐】编写单元测试代码遵守 BCDE 原则
以保证被测试模块的交付质量。
B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
nndC：Correct，正确的输⼊，并得到预期的结果。
D：Design，与设计⽂档相结合，来编写单元测试。
E：Error，强制错误信息输⼊（如：⾮法数据、异常流程、业务允许外等），并得到预期的结果。
10.【推荐】对于数据库相关的查询，更新，删除等操作
不能假设数据库⾥的数据是存在的，或者直接操作数据库把数据插⼊进去，请使⽤程序插⼊或者导⼊数据的⽅式来准备数据。
反例：删除某⼀⾏数据的单元测试，在数据库中，先直接⼿动增加⼀⾏作为删除⽬标，但是这⼀⾏新增数据并不符合业务插⼊规则，导致测试结果异常。
11.【推荐】和数据库相关的单元测试，可以设定⾃动回滚机制
nerd
不给数据库造成脏数据。或者对单元测试产⽣的数据有明确的前后缀标识。
注：springboot会⾃动回滚，若不想回滚则添加 @Rollback(fal) 注解
正例：在阿⾥巴巴企业智能事业部的内部单元测试中，使⽤ ENTERPRISE_INTELLIGENCE UNIT_TEST 的前缀来标识单元测试相关代码。
12.【推荐】对于不可测的代码在适当的时机做必要的重构
使代码变得可测，避免为了达到测试要求⽽书写不规范测试代码。
13.【推荐】在设计评审阶段
开发⼈员需要和测试⼈员⼀起确定单元测试范围，单元测试最好覆盖所有测试⽤例（UC）。
14.【推荐】单元测试作为⼀种质量保障⼿段
在项⽬提测前完成单元测试，不建议项⽬发布后补充单元测试⽤例。
15.【参考】为了更⽅便地进⾏单元测试，业务代码应避免以下情况
构造⽅法中做的事情过多。
存在过多的全局变量和静态⽅法。
存在过多的外部依赖。
存在过多的条件语句。
说明：多层条件语句建议使⽤卫语句、策略模式、状态模式等⽅式重构。
补充：卫语句
if（it ==活的）{
if（it ==⼈）{
if（it ！=⼥⼈）{
return不喜欢；
}el{
return喜欢；
}
cet3成绩查询}el{
return不喜欢；
}
}el{
return不喜欢；
}
// 改成卫语句
if （it ！= 活的）{return 不喜欢}
if（it！=⼈）{return 不喜欢}
if（it！=⼥⼈）{return 不喜欢}
if（it == ⼥⼈ && it == 活的） {return 喜欢}
if（其他任何情况）{return 不喜欢}
16.【参考】不要对单元测试存在如下误解
那是测试同学⼲的事情。本⽂是开发⼿册，凡是本⽂内容都是与开发同学强相关的。
单元测试代码是多余的。系统的整体功能与各单元部件的测试正常与否是强相关的。
单元测试代码不需要维护。⼀年半载后，那么单元测试⼏乎处于废弃状态。
单元测试与线上故障没有辩证关系。好的单元测试能够最⼤限度地规避线上故障。⼋、上线规约
1.git管理
