代码整洁之道-读书笔记之单元测试

TDD:测试驱动开发,先写测试,再写逻辑代码,通过单测,写逻辑代码,依次循环,知道所有逻辑都完成

1. TDD 三定律

第一定律:在编写不能通过的单元测试前,不可变写生产代码。

第二定律:只可编写刚好不可通过的单元测试,不能编译也算不通过。

第三定律:只可编写刚好足以通过当前失败测试的生产代码。

2. 保持测试整洁

有人认为测试代码不用遵循生产代码的质量标准

  1. 变量名不用好
  2. 测试函数不必短小和具有描述
  3. 测试代码不必做良好的设计和仔细划分
  4. 测试代码只要还能工作即可

不好的测试带来的问题

  1. 后期修改成本高
  2. 新增测试代码难度大
  3. 可能需要丢弃测试代码,直接使用无测试的代码,风险高

所以测试代码和生产代码一样重要。

测试的好处

保证生产代码的可扩展、可维护、可复用

改着放心,用着舒心

3. 整洁的测试

可读性是测试代码最重要的衡量指标,要保证测试代码的明确、简介、还有足够的表达力

测试的三个环节

give(准备数据)

when ( 执行逻辑)

then (验证逻辑)

看一个例子

package com.xxx.mas.cd.platform.service;

import com.xxx.mas.cd.platform.TestHelper;
import com.xxx.mas.cd.platform.common.config.AppPipelineConfiguration;
import com.xxx.mas.cd.platform.controller.dto.pipeline.AndroidAppPipelineGenerateFrontParamRequest;
import com.xxx.mas.cd.platform.controller.dto.pipeline.AppPipelineGenerateFrontParamResponse;
import com.xxx.mas.cd.platform.service.android.AndroidAppBuildParamConfigService;
import com.xxx.mas.cd.platform.service.android.AndroidAppBuildService;
import com.xxx.mas.cd.platform.service.android.AndroidBaseProjectBuildConfigParamService;
import com.xxx.mas.cd.platform.service.android.AndroidProjectRegisterService;
import com.xxx.mas.cd.platform.service.pipeline.AndroidAppPipelineConfigService;
import com.xxx.mas.common.entity.dto.pipeline.AppPipelineConfigGeneratorDTO;
import com.xxx.mas.common.proxy.GitProxy;
import com.xxx.mas.common.utils.JsonUtils;
import org.apache.velocity.app.Velocity;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.modules.junit4.PowerMockRunner;

import java.io.IOException;

import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.ArgumentMatchers.any;
import static org.powermock.api.mockito.PowerMockito.doReturn;
import static org.powermock.api.mockito.PowerMockito.when;

@RunWith(PowerMockRunner.class)
public class AndroidAppPipelineConfigServiceTest {
	@Mock
	private AppPipelineConfiguration appPipelineConfiguration;
	@Mock
	private GitProxy gitProxy;
	@Mock
	private AndroidProjectRegisterService androidProjectRegisterService;
	@Mock
	private AndroidBaseProjectBuildConfigParamService androidBaseProjectBuildConfigParamService;
	@Mock
	private AndroidAppBuildParamConfigService androidAppBuildParamConfigService;
	@Mock
	private AndroidAppBuildService androidAppBuildService;
	@InjectMocks
	private AndroidAppPipelineConfigService androidAppPipelineConfigService;

	@Before
	public void init() {
		MockitoAnnotations.initMocks(this);
		Velocity.init();
	}

	@Test
	public void testGenerateAppPipelineFrontTemplate() throws IOException {
		AndroidAppPipelineGenerateFrontParamRequest param = AndroidAppPipelineGenerateFrontParamRequest.builder()
				.applicationId("com.xxx.calculator")
				.appPipelineBuildType("test")
				.build();
		String templateParam = "{\"git\":{\"url\":\"git@git.xxxx.com:QaTools/calculator.git\",\"branch\":\"master\"},\"type\":\"test\",\"application_id\":\"com.xxx.calculator\",\"gradlew_path\":\"gradlew\",\"project_build_file_root_path\":\"build.gradle\",\"module_build_file_path\":\"app/build.gradle\",\"app_module\":\"app\",\"build_variant\":\"fullRelease\",\"gradle_cache_dir\":null}";
		String androidPipeline = TestHelper.getResource("android_pipeline_param.json");
		String expectResult = TestHelper.getResource("android_generate_pipeline_front_template.json");
		AppPipelineConfigGeneratorDTO appPipelineConfigGenerator = AppPipelineConfigGeneratorDTO.builder().templateParam(templateParam).build();

		AndroidAppPipelineConfigService androidAppPipelineConfigServiceSpy = PowerMockito.spy(androidAppPipelineConfigService);
		doReturn(appPipelineConfigGenerator).when(androidAppPipelineConfigServiceSpy).processAppPipelineConfig(param);
		when(gitProxy.getFileContent(any(), any(), any())).thenReturn(androidPipeline);

		AppPipelineGenerateFrontParamResponse result = androidAppPipelineConfigServiceSpy.generateAppPipelineFrontTemplate(param);

		assertThat(JsonUtils.objectToJson(result)).isEqualTo(expectResult);
	}

}

4.每一个测试必须有断言

也就是我上面说的then这个阶段,如果我们只是进行执行逻辑,缺不严重逻辑,这样的测试也就没什么意义了

每一个测试只测一种case

开发中一个方法可能存在多种业务逻辑,我们应该每一种case进行一次单独测试编写

5.R.I.R.S.T

测试遵循的5条规则

快速:测试代码应该执行快,以便于频繁的执行测试

独立:测试和测试之间应该相互独立,不能一个测试作为另一个测试的条件,每一个测试都是可以独立运行的

可重复:测试应该是可以重复执行的,而且获的结果是一致的

自足验证: 测试一定是有断言的,可以自我验证逻辑的正确性

及时:测试应该和生产代码同时编写。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

特特专属

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值