记得恰好是在一个月前的今天，我发布了lcut(轻量级C语言单元测试框架)0.1.0版本 。由于发布仓促，文档没能及时跟上。在stackoverflow的一个关于单元测试的帖子 上，一位叫Craig McQueen的朋友也给出了建议：“Some documentation would be helpful. Project background and goals, a features list, advantages over existing alternatives, etc would be helpful for people who are checking it out for the first time.” 看完这个建议后心里那个汗啊！不过一想到用E文编写文档心里就有些打怵。就这样在这一个月里文档依旧没有改观:(。不过，lcut本身还是有一些进步的，这两天一直规划着为lcut增加mock的支持，今天终于将这个功能加进了lcut，并发布了lcut-0.2.0-beta版，欢迎大家试用，并提出意见和建议。 ...
上午对一段代码进行单元测试，由于需要用到mock，所以选择使用cmockery 作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。 编写一个用例后，Build，提示出错：multiple definition of `malloc’。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居然被link了两次，类似于下面的这种错误情形： $ gcc testmain.c malloc.o malloc.o malloc.o: In function `malloc’: malloc.c:(.text+0×0): multiple definition of `malloc’ malloc.o:malloc.c:(.text+0×0): first defined here collect2: ld returned 1 exit status ...
基于各种xUnit框架的单元测试早已不是什么新鲜玩意儿，不过在"古老"的C语言领域，还尚未有哪种框架可以成为“寡头”。 记得2005年末的时候，初出茅庐的我吸取xUnit的设计思想在业余时间编写了一个轻量级的C单元测试框架lcut(Lightweight C Unit Test framework)，当时还写了一篇文章《C单元测试包设计与实现》记录了最初的设计和实现思路。本打算将这个小工具在部门内至少是项目内推广，可无奈当时部门内部尚未认识到使用框架工具进行单元测试的好处，或者尚未形成此种技术风气，当时的我也是“人轻言微”，因此这个小工具也没能吸引足够的眼球。这么长时间以来，都是我自己一直在使用， 其间，lcut做了两次小规模修改。特别是最后一次修改，通过增加测试用例执行的返回状态(增加LCUT_TEST_RESULT()宏)，让lcut可以与一些持续集成工具（如cruisecontrol.rb)结合在一起使用。 ...
如发现本站页面被黑，比如：挂载广告、挖矿等恶意代码，请朋友们及时联系我。十分感谢！ 商务合作请联系bigwhite.cn AT aliyun.com 欢迎使用邮件订阅我的博客 输入邮箱订阅本站，只要有新文章发布，就会第一时间发送邮件通知你哦！ ...
曾经在多篇blog中报怨过：用C语言写业务逻辑实在是让人身心忐忑不安，再加之C语言自有的"特点"，让其与"单元测试"始终若即若离，曾经尝试过写了一个轻量级C Unit Testing lib，至少目前我依旧在用，但多用在编写独立算法以及底层库的场合。业务层少有使用。业务层多是遗留系统，当初前辈们设计时对可测性考虑不够周全，导致现在无法很好的将各个部分独立抽出进行测试，虽然我们也在做着类似"重构"的工作，但鉴于规模较大，不能一蹴而就，我们需要一步一步找出使用C应对各种单元测试情况的方法。这里说说Mock Test。 ...
每天早晨都是坐公司的班车上班的，从家到公司大约需要40分钟，这段时间不短也不长。为了打发时间，也曾经想过要充分利用这段时间，我选择过听音乐、看书。但音乐听时间长了就听烦了；在车上看书时间长了还有些头晕，所以多数时间我还是选择"思考"。“思考"的同时，眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。 ...
自从去年年初搬到新办公室后，各个项目组都分到了各个独立的空间了，平时’抬头不见低头见’的情形减少了，随意拉把椅子坐下来谈技术的情形也减少了，随之而来的是项目组’各自为战’，经过近一年的发展，各个项目组在局部的发展上已经出现差异了。 ...
又是老生常谈-‘单元测试’，说实话自己在单元测试上是’语言上的巨人，行动上的矮子’，属于那种说的比做的多的人^_^。不过也不能说什么也没做。记得去年年末的时候自己还设计并实现过一个简单的’C语言单元测试包‘呢^_^，至今这个包仍然还在使用呢。不过大多数的单元测试都不像想象中那样简单，我们在介绍单元测试的时候，大多拿Add、Sub等作例子，这样当然有好处，简单易懂。其实学习单元测试初期关键是学习单元测试的思想，所以这些Add、Sub也能满足需求。不过在真正的项目中，单元测试大多做起来较为困难，我是在Unix上做C开发的，Java的咱暂先不提，也没什么资格提，虽然曾经花过一段时间专心研究过，还写过些Java学习心得，但是毕竟没做过实际的项目，说起来心里也发虚。 ...
在Java、C++和C#等高级语言的单元测试正进行的如火如荼的时候，C好像做了看客，冷清的躲在了一个不起眼的角落里。C并不是没有单元测试工具，像Check和CUnit这样的工具也很有名气，只是和大名鼎鼎的JUnit比起来，还是显得有些英雄气短。很多大型的C项目，如APR等都没有使用像Check、CUnit这样通用的单元测试框架，而是另起炉灶自己编写。其实编写一个仅能满足单个项目需要的C单元测试工具包并非难事。在部分参考APR的ABTS的前提下，我们也来设计一套自己的简单的C语言单元测试包。 鉴于减少复杂性，我们的目标仅仅是设计和实现一套能在单进程、单线程下工作良好的C单元测试包，我们暂且将之命名为CUT – C Unit test Toolkit。 1、CUT涉及的术语解释 曾经接触过多个有名的单元测试框架如JUnit、CppUnit、TestNG等，它们在对单元测试某些概念的理解上并不是全都一样的。这里我们也有我们自己的定义。 a) 一个逻辑unit test包含至少一个或者多个suite; b) 一个suite包含至少0或者多个test case; c) 每个test case中至少包含1个或者多个“断言类”语句。 ...
Tony : Hi Alex ! you just looks like drowing in your project. what is up? Alex : 我们的项目要求引入单元测试，but i’ve no experience in unit test. Tony : i think cppunit is your best choice. Alex : 是的，我刚从网上把它down了下来，正准备研究它呢。 Tony : Really ? I have done some practice on unit test before. would you like me to join you? Alex : Oh Tony, I’m so glad that you could help me ! Tony : My pleasue ! Alex : 我们从哪里开始呢？ Tony : The simplest case! 我们拿一个最简单的例子吧。now we have a class with the name “SimpleCalculator” and it has four basic methods ‘add’, ‘sub’, ‘mul’ and ‘div’, All we should do is to test whether these methods run as same as we expect. First of all , complete the “SimpleCalculator” class, Alex. Alex : It is simple! ...