测试对于软件开发的意义, 勿需再多言语阐述.
而在所有的测试当中, 单元测试的粒度是最小的, 是进入其他阶段测试的门槛.
以上的话语虽然可能有人看不惯, 但当有过不一样的体会后, 总会得出一些不一样的看法.
关于单元测试, 目前接触最多的是<C++程序设计实践与技巧：测试驱动开发>这本书, 里面深入浅出的介绍了各种单元测试的用法, 何时使用, 该怎么用. 同时不同的张杰都有完整的小项目贯穿整个章节. 该书于我当下, 有极深的印象和收获.
书中主要是使用gtest进行单元测试, 其次还有cppunit. 所以当下进行的单元测试主要使用的也是是gtest(谷歌出品), 网上有一个专门介绍gtest的系列--CoderZh大大的玩转Google开源C++单元测试框架GoogleTest系列, 可以移步围观.
两个接触点, 前者比较接地气, 从项目出发, 可以更多的熟悉gtest单元测试的使用, 流程以及作用; 后者前面较为通俗易懂, 也附有例子, 但其系列的目的主要是探索其框架原理, 更可以在吃通之后拓展自己的测试框架. 前者节奏较缓, 毕竟书的篇幅摆在那里, 后者可以领入门, 但入门到原理的跨度过大, 需要其他的来源的认知进行辅助.
言归正传, 前文提到的工程目录, 有一个专门的unittest目录, 这个目录就是专门用于单元测试的归类的.
里面包含gtest所需要的文件(头文件与库), 专门为单元测试定义的参数(例如有些跨平台的类型定义, 必需的参数等)以及单元测试工程的文件夹:
由于单元测试在某些情况下, 必定需要使用到mock进行, 所以这里选用了vs2015作为单元测试的环境. 所以对应的gtest库版本也需要使用vs2015版本的, 此处曾经掉过坑.
先看看unittest的工程:
有没有一种很熟悉的感觉? 那base, 那tutorial, 那熟悉的五个类名字...
是的, 整个单元测试的工程, 完全是受上文所提到的测试驱动开发这本书的影响而搭建的测试驱动开发的工程.
该工程完全可以在PC端对各自模块所有的功能进行测试验证, 通过测试后, 可以再使用对应平台的脚本进行编译生成真正的目标.
搭建这个工程的主要原因, 有两个:
第一, 受到测试驱动开发的影响, 其虽然在前期的投入较大, 但越到后期, 其所起到的作用就会越明显.
第二, 苦于之前开发调试测试的苦逼境地, 让我有一种极可能双手不离开键盘/鼠标, 可以测试验证完所有功能点的冲动.
于是, 基于测试驱动开发的工程就这样诞生了.
网上看到很多关于测试开发驱动与敏捷开发的争辩, 这里不多说, 仁者见仁智者见智, 适用于自己能提高自己效率的就是好的. 不同环境有不同选择.
至此, 关于已经践行, 并且正在发挥效用的测试部分已经完成规划到落地.
但是, 当前整个测试, 只是各自模块的测试, 所有模块功能之间的交互测试, 联合底层协议处理的多模块功能点, 整个应用的逻辑测试.....这些多模块以及程序主体之间的交互测试呢?
毕竟, 这些才是真正撑起一个完整软件的功能点, 单个模块, 那是组成功能点的基石.
当前这部分处于规划当中, 其中包括整个测试的运行环境/测试用例/测试数据/实现方式/服务器搭建/环境模拟...都还在规划当中, 虽然当前并无得到公司的支援, 孜孜独行, 但既可以点亮自己的技能点又可以提高效率, 何乐而不为呢?
一个人的风景, 只有自己的脚印.