单元测试

TDD是敏捷开发的核心实践之一， Ruby On Rails的创始人David Heinemeier曾说，当年它打开了一扇门，让自己看到了高质量代码的全新世界。然而，TDD太难，成本太高。如果对TDD进行改进，消灭它的主要成本，并放大它的效益，就得到了一个大幅提升代码质量、大量降低开发成本的开发方式，这种开发方式，就是easy TDD，简称eTDD。eTDD如何做到消灭TDD的主要成本、放大TDD的效益呢？答案是利用工具：由工具完成苦活、脏活、重活；由工具描述程序行实现可视编程。

有一种说法：程序员测自己的代码效果不好，因为测试是找错，程序员不愿意去证明自己是错的，别人测效果才好，对吗？这种说法是根本错误的，误导了无数人。正好相反，单元测试要自己测效果才好，别人测则几乎没有效果，除非有函数级的详细文档。单元测试的三种方式：程序员编码同时测试、程序员编码后测试、由别人测试，成本的比例大概为1:3:5，测试效果的比例大概为5:3:1。

用开源C/C++单元测试框架做C/C++单元测试，费钱、费力、误事，极其昂贵，为什么？

看视频，快速掌握C/C++单元测试。主讲老师拥有十多年单元测试实践，直接服务过的企业就达上百家。课程抛弃了宽泛而不能落地的理论，直面企业项目的单元测试难题，深入浅出地讲授C/C++单元测试的问题、思路与方法。在此课程的基础上，学员只需要经过一些练习，就可以在实 际的开发中应用单元测试、TDD、ETDD。

C/C++单元测试入门很简单，相关文章、教程、书籍很多，但理论通常跟实践脱节，学了一肚子理论，做起来可能还是老虎吃天，无从下手。我们需要一部简明扼要、贴近实际、边学可以边做练习、学完就能用的教程，简而言之，一部可执行的C/C++单元测试教程，Visual Unit 4的示例集就是这样的一部教程。

【摘要】本文分析了传统单元测试技术的不足，提出了表格驱动的单元测试技术，新技术可以大幅降低单元测试的难度及综合成本，用户不需要编写测试代码，测试工作效率通常是现有技术的五倍以上。新技术已在C/C++单元测试工具Visual Unit 4中成功应用。这是第一节。一、传梳单元测试技术的缺陷分析    单元测试是软件开发过程中保证代码质量，提升开发产能的重要手段。    单元测试的基本方法是利用测试驱动

嵌入式测试通常涉及硬件的模拟与控制，需要在单元测试用例中随意模拟和控制硬件行为，以及模拟中断对全局变量的修改，并解决死循环、超时等问题。使用Visual Unit 4，通过在测试用例中设置内部输入，可以随意模拟和控制硬件行为；利用测试用例的多次赋值功能，可以轻松解决死循环、超时等问题。用Visual Unit 4做嵌入式单元测试特别舒服。

单元测试是最早阶段的软件测试，面对的目标最小，可以综合使用黑盒测试方法和白盒测试方法，按理说，单元测试用例的设计应该是最简单的，但实际上，单元测试用例的设计常让人感觉无从下手，这是什么原因？是代码真的不具有“可测性”吗？还是单元测试方法不对？正确的单元测试方法是什么？单元测试工具应该具备什么样的功能，才能支持快速地构建测试用例？ 这些问题，这里将一一解答。