简单单元測试思想

一个项目又非常多模块组成,当我们每次完毕一个模块的时候,就应该測试该功能是否

可以执行正确。然后再写下一个模块,不要等全部模块写完了再总体測试,这样到时候非常

难找到问题(当然高手除外)。

所以作为一个project师,写測试用例是一个主要的技能。

那怎样写測试用例呢?

事实上就是使用自己的模块,看执行的结果是否跟期望的结果一致。

比方例如以下,写了一个add函数,要測试它,我们写一个test_add函数。

#include <stdio.h>
int add(int a,int b)
{
	return a+b;
}

int test_add(void)
{
	int ret = 0;
	ret = add(1,1);
	if(ret != 2)
	{
		return 1;
	}
	ret = add(2,2);
	if(ret != 4 )
	{
		return 2;
	}
	ret = add(3,3);
	if(ret != 6 )
	{
		return 3;
	}
	return 0;
}
int main()
{
	int ret = 0;
	ret = test_add();
	if(ret != 0)
	{
		//这里依据返回值来确定究竟是哪条測试出错。
		printf("test failed,ret = %d\n",ret);
	}
	else
	{
		printf("test ok!");
	}
}

当然也能够用一些开源的測试代码,下面是两个简单的语言单元測试框架。

比方 cutest ,简单的c单元測试  见链接 http://pan.baidu.com/s/1hqeg7qO

CUnit:  以静态库的形式提供给用户使用,用户编敲代码的时候直接链接此静态库就能够了。它提供了一个简单的单元測试框架,而且为经常使用的数据类型提供了丰富的断言语句支持。见链接 http://pan.baidu.com/s/1gd9WCgV

简单单元測试思想

时间: 2024-11-13 03:17:13

简单单元測试思想的相关文章

【Android进阶】Junit单元測试环境搭建以及简单有用

单元測试的目的 首先.Junit单元測试要实现的功能,就是用来測试写好的方法是否可以正确的运行,一般多用于对业务方法的測试. 单元測试的环境配置 1.在AndroidManifest清单文件的Application节点下.引入单元測试使用的库 2.在AndroidManifest清单文件与Application节点平行的节点中.加入instrumentation节点 以下是一个完整的配置的代码 <manifest xmlns:android="http://schemas.android.

[PYTHON]一个简单的单元測试框架

近期尝试了一下TDD(測试驱动)的模式.感觉效果不错.在此总结一下,同学们假设有更好的办法,一定要告诉我:) 1. 每一个功能模块(文件),配一个单元測试模块. 以手头这个项目为样例:有LogCat.py, LogModel.py, SceneBuilder.py 三个模块,那么就对应的新建LogCatTest.py, LogModelTest,SceneBuilderTest.py三个文件 2. 每一个函数都对应写一个单元測试例. 比方:在LogCat.py里有三个函数: def parseD

Android 进行单元測试难在哪-part3

原文链接 : HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 1) 原文作者 : Matthew Dupree 译文出自 : 开发技术前线 www.devtf.cn 译者 : chaossss 校对者: tiiime 状态 : 完毕 在 Android 应用中进行单元測试非常困难.有时候甚至是不可能的.在之前的两篇博文中,我已经向大家解释了在 Android 中进行单元測试如此困难的原因.而上一篇博文我们通过分析得到的结论是:正是 Google 官

太白---落燕纷飞第一重 Android单元測试Instrumentation和irobotium

PS:叫太白---落燕纷飞纯粹好玩(天涯明月游戏画面感,打击感,碰撞尽管做的不尽人意,可是太白这个职业还是不错,用作开头,,做个旁白而已). 这里的单元測试不管是instrumentation还是irobotium都不适用于游戏,游戏的自己主动化能够參考公司内wetest的基于引擎的对象识别自己主动化解决方式 or 前面用sikuli的方案.这里仅适用于传统行业Application范畴. 但基本思想类似,都是找到相应的对象,运行相应的方法,而这里的被測目标是详细的class里面的某个funct

C语言单元測试

对于敏捷开发来说,单元測试不可缺少,对于Java开发来说,JUnit非常好,对于C++开发,也有CPPUnit可供使用,而对于传统的C语言开发,就没有非常好的工具可供使用,能够找到的有这么几个工具: CuTest -- CuTest(Cute Test)是一个很easy的C语言单元測试工具.在使用它的时候,仅仅须要包括两个文件“CuTest.c CuTest.h”,然后就能够写測试用例,进行測试了.它对用例差点儿没有管理功能,报表输出也很easy,能够用来试验单元測试的基本想法. CUnit -

利用Continuous Testing实现Eclipse环境自己主动单元測试

当你Eclipse环境中改动项目中的某个方法时,你可能因为各种原因没有执行单元測试,结果代码提交,悲剧就可能随之而来. 所幸infinitest(http://infinitest.github.io/)提供了一个Continuous Testing插件,以及时自己主动执行单元測试.尽管会多占一些CPU资源,但开发者的硬件谁会不留一点余地呢?大不了,音乐.视频.360卸载就OK了.安装方法有两种: (1)使用"Install new software",输入地址:http://infi

在Eclipse中使用JUnit4进行单元測试(0基础篇)

本文绝大部分内容引自这篇文章: http://www.devx.com/Java/Article/31983/0/page/1 我们在编写大型程序的时候,须要写成千上万个方法或函数,这些函数的功能可能非常强大,但我们在程序中仅仅用到该函数的一小部分功能,而且经过调试能够确定,这一小部分功能是正确的.可是,我们同一时候应该确保每个函数都全然正确,由于假设我们今后假设对程序进行扩展,用到了某个函数的其它功能,而这个功能有bug的话,那绝对是一件非常郁闷的事情.所以说,每编写完一个函数之后,都应该对这

[iOS翻译]《iOS7 by Tutorials》在Xcode 5里使用单元測试(上)

简单介绍: 单元測试是软件开发的一个重要方面.毕竟,单元測试能够帮你找到bug和崩溃原因,而程序崩溃是Apple在审查时拒绝app上架的首要原因. 单元測试不是万能的,但Apple把它作为开发工具包的一部分,不仅让你创作的APP更稳定,并且提供了一致.有趣的用户体验,这些都是让用户给你五星评价的源泉.iOS7提供了一个升级的单元測试框架.让你在Xcode中执行单元測试更为easy.当你完毕这一章节,你将学会怎样给现有app加入測试--并有可能培养出对编写測试的热爱! /* 本文翻译自<iOS7

iOS单元測试:Specta + Expecta + OCMock + OHHTTPStubs + KIF

框架选择 參考这篇选型文章,http://zixun.github.io/blog/2015/04/11/iosdan-yuan-ce-shi-xi-lie-dan-yuan-ce-shi-kuang-jia-xuan-xing/,尽管结论不一定全然适用,可是关于框架对照的地方还是值得阅读的.基于这篇文章,排除Kiwi框架之后,决定參考一些项目的源码,了解他们使用的測试方面的框架. 首先,參考https://github.com/artsy/eigen开源项目,其内部总体结构很完整,开发流程也很