单元测试代码比产品代码还要多?

[图一] 是单元测试代码?

[图二] 是产品代码?

显而易见的是, 单元测试代码比产品代码还要多, 这合理吗?

当然合理!

产品代码虽然是只有短短的几行; 处理订阅者订阅赛马的消息?

但, 却会衍生出许多不同的使用者场景; 如: 没有订阅者订阅, 只有单一或多个订阅者, 某个订阅者重复订阅, 某个订阅者取消订阅…..等等?

单元测试, 根据这些不同的使用者场景, 分别有相对应的单元测试代码 (测试用例) ?  所以, 单元测试代码自然会比产品代码还要多?

但, 这样的付出 (投资) 绝对是值得的?

因为, 唯有如此所形成的 “自动化单元测试”,  才能使产品可在 “最短的时间内反馈”, 既有产品的架构, 功能与质量是否已被所新增的代码 (功能) 所破坏?

所以, 我们应该真正专注的是, 单元测试的 “测试用例的有效性” , 而不是表面的单元测试代码的行数?

package test.java.com;

import main.java.com.Client;

import main.java.com.Message;

import main.java.com.RaceResultsService;

import org.junit.Before;

import org.junit.Test;

import static org.mockito.Mockito.mock;

import static org.mockito.Mockito.never;

import static org.mockito.Mockito.verify;

/**

* Created by ScalaMind on 2015/3/3.

*/

public class RaceResultsServiceTest
{

private RaceResultsServiceraceResults;

private Messagemessage;

private ClientclientA;

private ClientclientB;

@Before

public void setUp() {

raceResults =
new RaceResultsService();

message =
mock(Message.class);

clientA =
mock(Client.class,
"clientA");

clientB =
mock(Client.class,
"clientB");

}

// zero subscribers

@Test

public void notSubscribeClientShouldNotReceiveMessage() {

raceResults.send(message);

verify(clientA,
never()).receive(message);

verify(clientB,
never()).receive(message);

}

// one subscriber

@Test

public void subscribedClientShouldReceiveMessage() {

raceResults.addSubscriber(clientA);

raceResults.send(message);

verify(clientA).receive(message);

}

// two subscribers

@Test

public void messageShouldBeSentToAllSubscribedClients() {

RaceResultsService raceResults=
new RaceResultsService();

Message message
= mock(Message.class);

raceResults.addSubscriber(clientA);

raceResults.addSubscriber(clientB);

raceResults.send(message);

verify(clientA).receive(message);

verify(clientB).receive(message);

}

// subscribe more than once

@Test

public void shouldSendOnlyOneMessageToMultiSubscriber() {

raceResults.addSubscriber(clientA);

raceResults.addSubscriber(clientA);

raceResults.send(message);

verify(clientA).receive(message);

}

// remove a subscriber

@Test

public void unsubscribedClientShouldNotReceiveMessages() {

raceResults.addSubscriber(clientA);

raceResults.removeSubscriber(clientA);

raceResults.send(message);

verify(clientA,
never()).receive(message);

}

}

[图一: 单元测试代码]

package main.java.com;

import java.util.Collection;

import java.util.HashSet;

/**

* Created by ScalaMind on 2015/3/3.

*/

public class RaceResultsService
{

private Collection<Client>
clients =
new HashSet<Client>();

public void addSubscriber(Client
client) {

clients.add(client);

}

public void send(Message
message) {

for (Client
client :
clients)

client.receive(message);

}

public void removeSubscriber(Client
client) {

clients.remove(client);

}

}

[图二: 产品代码]

时间: 2024-12-20 00:32:44

单元测试代码比产品代码还要多?的相关文章

产品代码的建议标准

怎样的代码才能作为产品代码提交到代码库中,使系统能够持续健康地成长? 第一级: 无语法错误,编译通过, 能够启动应用: 消除警告与错误: 第二级: 简洁清爽的排版,合理的命名, 一致的风格, 适宜必要的注释: 第三级: 能够处理正常情况下的功能实现,保证正常情况下的逻辑正确: 第四级: 能够处理不合法输入,给出错误提示:能够处理可能出现的错误和异常,输出容易排错的日志: 第五级: 使用相互协作良好的短小方法: 消除一个方法中含有大段逻辑的情形: 第六级: 编写的代码有比较完善的单元测试用例:对错

代码和产品发布的几种方式

代码和产品发布的几种方式 最近有几个朋友提起”灰度发布"这个概念和相关的问题.想解释一下几种具体的发布方式(具体名称中文翻译不一定正确).他们的优缺点和实现难点. 这几种方式都可以作为快速运营的软件或者web服务公司逐步发布新代码或者新产品,边尝试边改进的方法,这些方法可以避免一次发布里面某个产品/代码的漏洞对网站产生瞬间毁灭性的后果. 这几种方式各有优缺点和难点,根据实际情况一个公司可能使用不同的方法做不同的发布. 分步代码发布(multi-phase code push):这是敏捷开发的团队

多产品代码架构

对于多产品代码来说如何,对于不同产品相同属性不同参数如何简单code 举个例子: 其实很简单,比如说你们班有很多小伙伴,如何设置信息呢,用到了struct struct STUDENT_S{ string name; int age; bool sex; string addr; ... }; struct STUDENT_S g_student_param[] = { {“Li Lei”, 12, true, "beijing"}, {"Han Meimei",

文档驱动式代码设计器——代码是设计出来的!

代码是敲出来的吗?是批量生成出来的吗? No no no,代码是设计出来的! 如果说到代码生成器,大家可能会想到三层.动软代码生成器.数据库表等等.其一般的思路是,先有数据库然后根据库里的表自动生成一系列的代码,包括实体类.持久化.业务层(空函数).页面代码等,还可以生成数据库文档.这个确实很好很强大,可以免除程序员的机械式的敲代码的工作. (“主要实现在对应数据库中表的基类代码的自动生成,包括生成属性.添加.修改.删除.查询.存在性.Model类构造等基础代码片断,支持不同3种架构代码生成,使

20155326《网络对抗》免考项目—— 深入恶意代码之恶意代码详解

20155326<网络对抗>免考项目--深入恶意代码之恶意代码详解 什么是恶意代码 恶意代码是一种程序,它通过把代码在不被察觉的情况下镶嵌到另一段程序中,从而达到破坏被感染电脑数据.运行具有入侵性或破坏性的程序.破坏被感染电脑数据的安全性和完整性的目的. 恶意代码生命周期 攻击目标: 个人计算机 服务器 移动智能终端 手机.平板等 智能设备 特斯拉汽车.智能家居.智能手表等 通信设备 路由器.交换机等 安全设备等 防火墙.IDS, IPS. VDS 攻击目标范围: 定点攻击 邮件.IP.域名.

代码规范及代码复审

1.对代码规范的讨论 编写一个程序是否需要代码规范?本人以为,规范当然得有,但也必须合理. 为什么我们需要代码规范?代码规范就是规定代码中某些格式必须遵守一定条件,比如缩进.变量命名.注释等.当制定了合理的规范后,不仅代码本身会显得美观,而且每个人都很容易读懂,代码的可维护性也大大增强.举个例子,甲程序里使用的变量名有input_msg,output_msg,decipher,每个符号之间均加了空格,而乙程序里则是随意地使用a,b,c等无意义的字母作为变量名,而且多个函数里重复使用相同名称的局部

Android 优化代码代码写作习惯代码规整

今天我想说说代码习惯: 刚开始学Android时相信很多新手都会有一个疑问,我们作为菜鸟除了技术上的不足到底哪点比不上大神呢?相信问这个问题的新手,肯定是一个不服输的人(不能叫愤青吧,我认 为愤青貌似是个贬义词)所以喜欢问问题,但是一些经验丰富的大神有的时候就会说自己百度,不行谷歌,这么简单的问题还问!这可能深深的伤害到我们菜鸟,但挺多时候是应 该我们自己动手找自己研究,其实作为菜鸟不是不喜欢动手自己找自己写,只是想有个捷径站在巨人的肩膀上,但是事实却不是这样的因为所有的问题要想记得更牢固,更清

使用Underscore.js的template将Backbone.js的js代码和html代码分离

这段时间在学习Require.js和Backbone.js的过程中,发现有些项目里的HTML代码都是写在View的js代码里面的,渲染的时候需要对Collection进行循环,再将HTML代码拼接上去,这似乎不是一件非常好的事情,因为将js代码和html代码融合到一起会增加代码的维护难度,而且这个过程中考虑到性能的因素,需要将HTML代码放到一个数组中,最后进行拼接,代码写起来比较麻烦.我看到他们的代码之后就在考虑是否有一种类似php模板引擎的东西可以将Collection传递进去然后渲染. 我

Java中代码点与代码单元(转)

摘要 本文介绍 Java 平台支持增补字符的方式.增补字符是 Unicode 标准中代码点超出 U+FFFF 的字符,因此它们无法在 Java 编程语言中描述为单个的 16 位实体(例如char数据类型).这些字符一般极少用,但是,有些会在诸如中文或日文人名中用到,因此,在东亚国家,政府应用程序通常会要求支持这些字符. Java 平台目前正在改进,以便支持对增补字符的处理,这种改进对现有的应用程序影响微乎其微.新的低层 API 在需要时能够使用单个的字符运行.不过,大多数文本处理 API 均使用