请问CppUTest怎样做多进程程序的测试？特别是mock要怎样进行？

[xish]

最近刚在公司的开发环境上安装了CppUTest，使用下来发现确实很方便，但是发现在对一个多进程并发调度的模块进行测试的时候发现mock遇到了问题，无论怎样安排mock的位置都无法按照预想的流程去执行。
关于多进程单元测试这方面，大家有什么好的建议么？

[Joseph Yao]

加AgileShanghai组。

Terry, 燎原，有这方面的经验分享吗？：）

On Feb 18, 2014, at 6:20 PM, xish <xis...@gmail.com> wrote:

最近刚在公司的开发环境上安装了CppUTest，使用下来发现确实很方便，但是发现在对一个多进程并发调度的模块进行测试的时候发现mock遇到了问题，无论怎样安排mock的位置都无法按照预想的流程去执行。
关于多进程单元测试这方面，大家有什么好的建议么？

--
--
您收到此信息是由于您订阅了 Google 论坛“Scrum Gathering”论坛。
要在此论坛发帖，请发电子邮件到 scrumga...@googlegroups.com
要退订此论坛，请发邮件至 scrumgatherin...@googlegroups.com
更多选项，请通过 http://groups.google.com/group/scrumgathering?hl=en 访
问该论坛
网站: http://scrumgathering.cn
微博: http://weibo.com/scrumgathering
 
---
You received this message because you are subscribed to the Google Groups "Scrum Gathering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumgatherin...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Terry]

Hi,

我对并发测试的一点见解。

CppUTest从根本上是不支持并发模块的单元测试的，也从来没有针对并发测试而做设计。做不到主要是因为CppUTest很有特色的内存泄露检查，还有mock的实现是不支持并发的（至少目前仍是这样）。如果不使用内存泄露检查和CppUMock的话，理论上来讲是可以支持带并发的测试的。

而CppUTest这样的设计也是有自己的考量的。合理的软件设计中业务逻辑应该由一些高度内聚的“单元“完成的，单元测试尤其擅长对这些内聚体进行测试，而这些内聚体中往往是没有并发的。换句话说，业务逻辑应该与并发逻辑分离开。

如果业务逻辑无法完全同并发逻辑分离开的话（举个例子，业务逻辑是由在两个线程间异步消息传递而完成的），那么在单元测试时用同步实现来模拟并发的话是个好的选择。

那么剩下来的就是针对并发时的时间特性的测试了。说实话，单元测试对此往往无能为力。理由是，并发本身就是把程序的执行和时间解耦开。而具体执行时到底是个什么顺序是由很多外在因素决定的，例如某次内存分配所花的时间、当时cpu的利用率等。单元测试本来就是要在断开与环境之间依赖的情况下进行，所以几乎与真实运行环境不可能一样。而且c/c++单元测试往往和产品不在同一个环境里，甚至不是同一个编译器。

所以我的结论是，

1.并发应与与业务逻辑尽量分离。

2.如果并发中有业务逻辑则用模拟并发的方式做单元测试

3.对并发的保证来自于好的和一致的并发策略，以及与真实环境接近的集成测试和系统测试。

br, Terry

--
您收到此邮件是因为您订阅了 Google 网上论坛的“agileshanghai”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 agileshangha...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/groups/opt_out。

[zhang...@gmail.com]

我基本赞同Terry的comments，但相对Terry高大上的解答，我再这里再补充一点：

1. 土鳖一点的回答mock安排的问题：CppUMock默认是Order忽略的，所以安排mock的ExpectCall是没有什么区别的，如果需要严格order，可以再调用MockFunctionCall的withCallOrder方法；

2. 

略高大上一点的回答：对业务逻辑来说，单元测试会显得更力不从心，就像Terry所说的，单元测试更关注高内聚的那块单元，而业务逻辑往往通过功能测试和系统测试cover。但是这里提到一点，如多线程的测试，线程与线程之间的某些细节的交互如果也交给功能测试甚至系统测试，粒度就小了，如果交给单元测试来做，粒度又过大。针对这种测试，可以基于单元测试框架来做模拟测试，通过模拟器喂数据，框架里检验具体的输出。如果线程之间的交互太复杂，模拟测试无法模拟，怎么办？我想这时的答案应该是重新设计代码，而不是如何在糟糕的代码上做更多的测试。

[Liao-Yuan Zhang]

才看到，Terry把我的想法都cover了... :p

./Eric

--

Cheers,
Liao-Yuan

twitter: http://twitter.com/zhangliaoyuan

[Terry]

1. 土鳖一点的回答mock安排的问题：CppUMock默认是Order忽略的，所以安排mock的ExpectCall是没有什么区别的，如果需要严格order，可以再调用MockFunctionCall的withCallOrder方法；

非也。CppUMock的实现不是线程安全的，所以和strictOrder没关系。

[Jones_Fong]

插播个话题，最近在看Google的ACC测试模型，想引入现行的项目使用，不知道大家是否有用过，有什么好的建议或使用经验可以分享？谢谢！

Best Regards!
方炯华（Jones Fong）
E-mail：fangji...@gmail.com
sina微博:@方较瘦1981