C/C++单元测试理论精要（四）
题外篇：单元测试难于长期坚持的原因与解决探讨
上一篇《单元测试效益》，有网友评论说：“单元测试的好处基本人人知道，就是难坚持！”。这一评论严重提醒了我，不错，“难坚持”也是一个普遍现状。如果不能坚持，那一切都是白搭。因此，这里插入一个题外篇，探讨单元测试难于长期坚持的原因与解决，抛砖引玉，希望大家踊跃讨论，共同找出使单元测试易以坚持的途径。
我以前主要关注如何做得了、做得快、做得好，几乎没有单独考虑长期坚持的问题，原因大概是：对我自己来说，这不是问题，我已经做了十年的单元测试，这十年，我写代码时基本上都是一边写一边测试。那么，是什么原因让我长期进行单元测试呢？
这十年分为两个阶段，后六年专门研究单元测试技术与工具，前四年做一些外包项目。如果说因为单元测试已经成为我的专业，所以自己当然要做，那么，这也不能解释前四年之所以能坚持的原因。正是因为前四年的单元测试经历，才使我后来专注于单元测试领域。
回首十年的单元测试历程，我发现从来就没有刻意去坚持。我不是一个理性而有毅力的人，比较喜欢率性而为，能够十年不间断去做同一件事情，应该是因为，这其中有什么东西吸引了我，让我自然而然地想做而不是强迫自己去做。
一件事情，如果需要理性的力量，去勉强坚持，时间长了，热情会减退，惰性渐占上风，慢慢的可能就放弃了，例如健康的饮食习惯。有些事情，虽然从理性方面看未必好，但却容易使人沉溺其中不能自拔，例如玩网络游戏。为什么会这样呢？后者具有眼前的和感性的吸引力，形成了“诱惑”，自然让人喜欢做，长期做。眼前的感性的吸引力，往往能轻易打败后期的和理性的好处。
我想，正是因为单元测试的某些“眼前的和感性的吸引力”，形成了“诱惑”，使我乐于去做，而不是勉强去做。那么，是什么产生了“诱惑”呢？为什么单元测试没有形成普遍的“诱惑”呢？我做的单元测试和一般的单元测试有什么不同吗？
回想起来，不同确实是有的，从一开始，我使用的工具都是自己参与开发的。当时由于找不到满意的工具，所以自行开发，功能都是自己最需要的。
这个工具的第一个版本，主要功能是生成测试代码，修改一下就形成用例了。
&nbs
相关文档：
//---------------------------------------------------------------------------
#include <vcl.h>
#pragma hdrstop
#include "Unit1.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
int flag=0; // ......
在软件开发这一高度抽象而且十分复杂的活动中，命名规则的重要性更显得尤为突出。一套定义良好并且完整的、在整个项目中统一使用的命名规范将大大提升源代码的可读性和软件的可维护性。
在引入细节之前，先说明一下命名规范的整体原则：
同一性
在编写一个子模块或派生类的时候，要遵循其基类或整体模块的命名 ......
XCode：你可以把它看成是一个开发环境，就好像Visual Studio或者Netbeans或者SharpDevelop一样的玩
意。你可以将Interface Builder认为是Visual Studio中用来画界面的那部分功能单独提出来的程序。
Objective-C：这是一种语言，就好像c++是一种语言，Java是一种语言，c#是一种语言，莺歌历史也是一
种语言一样。
Coco ......
试题5：编写一个函数，作用是把一个char组成的字符串循环右移n个。比如原来是“abcdefghi”如果n=2，移位后应该是“hiabcdefgh”
函数头是这样的：
//pStr是指向以'\0'结尾的字符串的指针
//steps是要求移动的n
void LoopMove ( char * pStr, int steps )
{
//请填充...
}
� ......
摘要：
在学习linux内核代码及一些开源软件的源码（如：DirectFB），经常可以看到有关
__attribute__的相关使用。本文结合自己的学习经历，较为详细的介绍了__attribute__
相关语法及其使用。
---------------------------------------------------------
声明：
此文为原创，欢迎转载，转载请保留如下信息
& ......
