ding

不错了，学习了，楼主结帐吧^_^

这么巧，我也正在学这个啊，不过拿你差远了，我是刚入门的。为什么要自己写测试框架呢，网上有很多非常好的单元测试框架啊。cppunit框架就可以。
没必要重复劳动啊，有现成的拿来用就是了。
虽然这样说，我也在试着自己写框架。祝福我们两个吧。

tdd还有点用处，unit test你就忘了吧。

用得不是很多boost好象有一个
另外看看:http://blog.joycode.com/peon/archive/2007/05/19/102754.aspx
简单介绍:http://www.mscto.com/testing/25721905.html
一般不对每个类一个test类,而是写一些用宏条件控制继承或者其他的形式绑上去,就像MFC实现一些功用借口一样~

楼上误解了，我没有自己写测试框架 我们就用  cpp unit

我问的问题 有些可能比较大，有些比较细节，

其实任何相关信息都欢迎，  甚至觉得它有多不好， 或者什么好书推荐

tdd还有点用处，unit test你就忘了吧。
================

tdd 不就是 用 unit test drive develop? 请指教 

俺还没做过测试，不过老多书里都有测试的讨论，比如代码大全有专门的章节，我看过现在基本忘完了，只记得tdd

up 学习

引用 7 楼 qhfu 的回复:

tdd还有点用处，unit test你就忘了吧。
================

tdd 不就是 用 unit test drive develop? 请指教

tdd不是utdd

引用 7 楼 qhfu 的回复:

tdd还有点用处，unit test你就忘了吧。 
================ 

tdd 不就是 用 unit test drive develop? 请指教 

 
test drive develop

一般不对每个类一个test类,而是写一些用宏条件控制继承或者其他的形式绑上去,就像MFC实现一些功用借口一样~

========
情况是 这样的： 有一个接口类A， 他会用到 另外一个类 B

类 A大概 1000行左右， 类B也差不多

B里面的功能主要是给A用的，可以理解为一个工具类， 当然以后也有可能给其他的类用，
有两种选择写 unit test：

1, 只针对 A的接口写，在测试中覆盖到B 的代码。
2， 分别真的 A 和 B的接口写，这样当然有可能B的一些接口重复测试。 

你会选哪一种呢？  

选择先把类A重构拆小了。
1000行的类基本是垃圾堆了。

[Quote=引用楼主 qhfu 的帖子:]
讨论： 关于 unit test. 

问题如下： 

1， 有多少人现在在项目中 会写 unit test？ 为什么写？ 觉得 unit tset带来好处了吗？ 
2， 大家在使用unit test的时候有什么心得体会， 或者经验？ 
3， 是否应该 为每一个 class 提供一个test 类，为每一个 publiic函数至少 提供一个测试， 还是可以只 考虑 接口类添加test class，只要 非接口类代码覆盖到了就可以了？ 
4， 是否应该为了 unit test 而在产品代码中 加入一些特殊的东西，比如只为测试用的代码？ 
5， 在使用 unit test过程中 有没有什么好的 方法或策略？ 
6， 任何 跟 unit test 、TDD、agile 等相关的 观点看法 都欢迎。 


我 接触这一方面时间不是太久，经历过一些项目 ，也看了一些书， 总体感觉效果不是太好。 

先说一下个人观点： 
1， unit test 是不错的， 特别是在以后 修改bug 或者添加新功能的时候， 很容易得到反馈让coding 更加有信心，有利于代码重构，保持代码干净。 
2， 容易促使 解开各种依赖， 为了能做unit test通常会把数据库，或者其他各种依赖封装起来，， mock出一个东西来，这样让代码的 耦合性降低，也是一个好处。 
3,  unit tset 会增加工作量，必须随代码修改而修改。 
4， 有的时候为了 unit，在产品代码中 加入一些本来 可能不需要的代码。 
5， 程序员有的非常不愿意写 unit tset case，质量低的  test case，会起副作用，test case 的质量也很难衡量。 
Quote]

楼主的理解已经不错了。
个人觉得哈：
1. 还是有项目写unit test的，也会用cpp-unit，虽然那不是很完美，不过也是需要的。
2. 不需要每个函数或class都写，不过重要的函数或clase是一定要的。都是按需要的。
3. 如果需要在代码里加测试代码，那就加。

关注

引用 13 楼 taodm 的回复:

选择先把类A重构拆小了。
1000行的类基本是垃圾堆了。

同意，尽可能地让类的接口最小化，否则维护起来就困难了！

引用 7 楼 qhfu 的回复:
tdd还有点用处，unit test你就忘了吧。
================

tdd 不就是 用 unit test drive develop? 请指教


tdd不是utdd

======
谢谢，我也明白 tdd 是 tset drive develop，我们一般是 unit test drive。。
如果是把这个系统拿起来run一下，有些系统来说run起来挺麻烦的，特别是大系统，这样子开发效率可能不太高，就是说 要在系统上能run起来都是先假设功能实现了。  

不知道你们如何做 tdd呢？ 

能做UT的，尽量做。

引用 13 楼 taodm 的回复:
选择先把类A重构拆小了。
1000行的类基本是垃圾堆了。

同意，尽可能地让类的接口最小化，否则维护起来就困难了！
============
重构是一个好建议，一直想这么干，不过由于一些其他原因，现在并没有做，接口最小话不代表类最小化，有的类不得不实现多个接口，呵呵。

1k行的类粒度太大，建议重构
关于A B的问题，当然要分开写，A对B的抽象不应该由测试去理解，测试只面向测试者提供的抽喜

编写单元测试的重要性
  在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试。这需要有一个粒度的把握。最大的粒度应该控制在一个类级别上，最合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么，实现什么。测试代码远远要比难以阅读和不会及时更新的需求文档更有价值。
 测试先行，鼓励对需求的理解。如果没有理解需求，你是不可能写出测试代码的，当然你也不可能写出好的实现代码。
  测试代码与其它文档相比会更有价值。当需求发生改变，实现代码也相应改变。而往往需求文档，设计文档得不到及时更新。测试代码相比那些过期的文档更具有价值。
  测试先行可以编写出最大覆盖率的测试代码。如果在方法的实现代码编写完后再编写测试代码，这时开发人员总是编写一个正确路径的测试代码。它已经很难全面的去分析其它分支逻辑。
  如果我们采用测试先行，那么就自动的完成了为所有的类都编写测试这个实践原则。为所有的类都编写测试会将为你带来非常多的好处:
   我们可以很好的使用自动化测试来测试所有的类。
   可以让我们放心的为类或方法添加新的功能。我们可以很容易的修改测试代码并验证修改后的代码是有用的代码。
   可以让我们放心的对代码进行重构和进行设计优化。重构和设计优化通常会关联到多个类及多个方法。如果我们为所有的类都编写了测试，我们就可以在重构代码后很轻松的进行测试我们的修改是否正确。
   为所有的类编写测试，可以让我们很容易的修改bug。当接到一个bug报告后，我们总是先修改测试代码，然后修改实现代码，使测试成功。这样不会因为修改一个问题而造成新问题的产生。
良好的单元测试策略给我们增强了对程序的信心,减少了bug的产生及bug的潜伏期。降低修改bug的代价。单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。

好理论啊~

确实挺理论的，我只是对这个概念有所了解，但是现在大家都在做。

前不久老大的话：

晨星  发表了迷你博客：单元测试的四个作用：（1）使代码可以放心被修改和重构，（2）迫使程序员从调用者的角度设计软件，从而使之更易于使用，（2）迫使程序员将软件写得易于测试和调用，从而有利用解耦，（4）文档功能。

学习

引用 21 楼 jia_xiaoxin 的回复:

编写单元测试的重要性
在编写代码之前先编写单元测试，并不是编写代码之前需要一次性为所有的类都事先编写单元测试。这需要有一个粒度的把握。最大的粒度应该控制在一个类级别上，最合适的粒度是控制在一个方法级别上。先为某一个方法编写测试代码，然后再为该方法编写实现代码，直到其测试通过后再为另一个方法编写测试代码，如此循环。单元测试在这里已经是一个契约规范了，它规范了方法应该做什么，实现什么。测试代码远远要…

不错，
有两点补充一下： UT 能起到文档的作用 ，接口定了之后开始写UT （一朋友公司的做法）

引用 24 楼 Kenmark 的回复:

前不久老大的话：

晨星  发表了迷你博客：单元测试的四个作用：（1）使代码可以放心被修改和重构，（2）迫使程序员从调用者的角度设计软件，从而使之更易于使用，（2）迫使程序员将软件写得易于测试和调用，从而有利用解耦，（4）文档功能。

如果能更详细点就好了，：） 

比如具体如何实施 UT ，在过程中碰到的问题，怎么解决，有什么心得或反馈，有什么技巧可以 在UT TDD中用到。

站坐，学习

学习

请老大把那个在程序人生回复的帖子链接贴出来

嗯，认真学习ing

我也要写单元测试，也用cppunit，用的不是很顺手
单元测试主要是为了修改某处代码后的回归测试，
A函数修改了代码，不会影响到B函数的单元测试结果。
单元测试要全自动的，由测试程序判断结果，不能加上人为判断因素。
单元测试环境不能手工构造，要由程序来来构造，运行完该用例需自动释放该环境，执行下一个用例。

单元测试覆盖率是一个评判标准，能达到80%，代码写非常好了。有工具可以计算覆盖率。

我覆盖率还不到10%，代码耦合度很高，许多还不符合单元测试规范。

但我发现cppunit是一个很好的测试工具，这个测试不是指规范的单元测试，是指自己定义的测试。
比如有一天你想知道_fullpath()这个函数的的功能，你也许会自己写个小程序来测试；第二天你又想知道
_access()这个函数的作用，你又会写一个小程序。这样就很麻烦了，小程序越来越多。
有了cppunit框架就很好管理了，_fullpath写一个测试函数，_access写一个测试函数，加入框架里就行了。
写的时候不需要死板的按照单元测试规范了，甚至不需要断言，直接把结果输出或者弹出一个对话框，
因为我们的目的不是回归测试，自己想怎么搞就怎么搞，cppunit框架只负责运行我们写的函数。
这样只需一个cppunit单元测试框架程序，我们就可以不断添加自己的函数并选择执行某个函数。
这样还能回过头来查找以前测试过的一些函数的用法啊等等，比较方便。

我现在在写stl的一些自己不熟悉的函数的测试，并分类，方便以后查找。

完善的自动化测试是重构的基础。

tdd，测试驱动开发
这个要有高水平经验丰富的有整体架构能力的人先做好设计才行
反正感觉有难度
一般是平行进行，一边开发一边写测试用例

引用 24 楼 Kenmark 的回复:

前不久老大的话： 

晨星  发表了迷你博客：单元测试的四个作用：（1）使代码可以放心被修改和重构，（2）迫使程序员从调用者的角度设计软件，从而使之更易于使用，（2）迫使程序员将软件写得易于测试和调用，从而有利用解耦，（4）文档功能。 

感觉挺难的，单元测试覆盖率高了，你差不多有写库和大框架的能力了，cppunit库自己对自己做了高覆盖率的单元测试。
我写着写着，很多地方就耦合起来了。

而且功力不够，又想提高覆盖率，会很痛苦，这个可能要慢慢不断历练吧。

楼上的因为单元测试偶合起来了？

如果坚持写unit test，应该是能更加帮助decouple 才对。

10%的覆盖率还是比较低的，可能原因就是各个类的耦合度太高了。

在一个已经有的大型系统中，我们要做的工作是 给它添加 ut case，让整个系统处于 每天都会run的 ut系统中，这样n多人一起开发的时候，修改bug，添加功能，甚至重构，的时候保证 不去给系统带进去坏的东西， 有点像每天都跑 回归测试一样，由于自动化回归测试，在这边不可行。

要做这件事情，甚至为了做 unit case 可能要去改product中已经run得很好的代码，现在问题是没有经验，不清楚什么才是正确的

mark

mark

LZ 活雷锋

小弟 学习中

学习啦

恩，可以学习一下~

1， 有多少人现在在项目中 会写 unit test？ 为什么写？ 觉得 unit tset带来好处了吗？ 
2， 大家在使用unit test的时候有什么心得体会， 或者经验？ 
3， 是否应该 为每一个 class 提供一个test 类，为每一个 publiic函数至少 提供一个测试， 还是可以只 考虑 接口类添加test class，只要 非接口类代码覆盖到了就可以了？ 
4， 是否应该为了 unit test 而在产品代码中 加入一些特殊的东西，比如只为测试用的代码？ 
5， 在使用 unit test过程中 有没有什么好的 方法或策略？ 
6， 任何 跟 unit test 、TDD、agile 等相关的 观点看法 都欢迎。 

1、一般来讲一个测试阶段需要有测试方案和测试用例，在cmm瀑布模型里的流程如下：
   
   需求分析（ST设计）->概要设计（IT设计）->详细设计（ut设计）->coding->ut测试执行->it测试执行->st测试执行
   而且这个模型在我们公司正在用，效果不错，这里面每一个测试阶段都是十分重要的，bug发现的阶段越靠前，公司付出的成本就越少，在UT、IT、ST中分别发现一个问题，成本是不同数量级的，ut就是编码后的第一道关卡，很重要
2、同意32楼
3、根据具体产品或测试策略划分测试粒度等级，从类到方法，到路径不等
4、我认为应该，但是我们的目的始终是减少维护成本，这是我们在做这件事情时需要考量的。
5、没有
6、没有

谢谢 大家！！！