还要从项目开始说。

刚来项目组，主体是医疗仪器中位机部分，基本的部署结构：

上位机UI(Ubuntu 18 + java) + 中位机(ARM+Ubuntu 18, C++)  + 下位机（N个下位机子系统，控制步进电机，各种传感器，反射计，大多数基于STM32F407 + RT-thread+C/C++）

现代的C++开发，UT是必不可少的，当前项目开发已经有3年以上，可是UT才刚刚开展，也不知道过往的项目交付流程中，是如何一步一步走过来的，调试纯粹依靠中位机实测，代价很大，也没有gdb，可以想象一路走来是何等是筚路蓝缕。

这也许是蹒跚爬行中众多中小型科技企业的一个非独有的现象，很多现代C++项目交付流程中的烂大街的经验，在部分企业中不一定能够很快用上。

而包含UT的中位机版本，实测中还会包含对真实数据库的修改，因此每次跑完后，可能留下一地鸡毛，记得刚来时，有一个同事的亲身经历，他为了调通一个总是莫名其妙crash又不知道调用栈的case，用了3天，期间疯狂加打印，疯狂各种小修改，这个还算幸运的。

嵌入式开发，通常开发和编译端都是基于Windows+WSL的组合，而代码运行是在ARM芯片上，交叉编译器只能最多支持到C++14版本。

UT的代价不可以如此之高的，编一个版本10分钟，好几个开发用同一台真实机器，很难保证不会互相影响，到最后，积极性很难保证，如何用恰当的工具快乐的开展TDD开发以及小规模重构，让工作多一些快乐，是当务之急的事情。

笔者新加入项目组后，决定必须做一点改进，毕竟简历上写着自己在UT方面称得上很会。

那就基于VC2022开搞。

1 搞定VC下的各种组件的编译（同一套代码，需要适配WIN32+GCC12 + 交叉编译）

2 搞定VC下的google test+ google mock

3 也要协助搞定WSL下的google test+ google mock

即一套代码，最少保证UT可以在三种不同环境上运行。

搞定1后，接下来搞定2，比较麻烦的是VC 2019版本开始默认可以支持google test但是不支持google mock，这个估计是微软方面有私心。

另外一个麻烦事一开始注意到，后来想法设法规避的，那就是项目ARM真实机器上跑的google test版本我居然没有找到完全一样的。

CSDN上有大神已经列出了比较详细的步骤。

这里再次赘述一下

下载googletest-1.14.0版本，确保安装了cmake

powershell 打开，mkdir build & cd build & cmake ../

然后打开build目录下的解决方案

在google test 解决方案这里，比如gmock属性页面

基本上，运行库选MTd（这个很重要，不知道有没有小伙伴用默认的最后也搞定了）

在ALL_BUILD 上面选择生成后，有如下4个库文件

再加上gest+gmock头文件，就得到了一个UT运行的必备组件，归置到某个目录中，笔者当前是和sln文件同级别的目录。

tree命令查看

D:.
├─include
│  ├─gmock
│  │  └─internal
│  │      └─custom
│  └─gtest
│      └─internal
│          └─custom
└─lib

笔者本地的解决方案演示如下，新建EventEngine_ut项目（console控制台，空项目或者控制台应用都可以，不要选静态库动态库之类的）

在EventEngine_ut上打开属性，配置如下

C/C++常规

代码生成的选项里面，仍然是多线程调试/MTd

链接器配置，附加库目录路径填好

输入里面的附加依赖项填好

差不多配置完毕，可以开始您的UT之旅了。

上面只谈到了搞定1 和2， 3的搞定是另外一个故事的。

熟悉CMake的兄弟姐妹可能会鄙视，我们一开始是没有cmake工程的，依靠当前1和2搞定的工程，通过工具cmake convertor导出初版的cmake 工程，然后改造，比较初级。

cmake convertor

后续再拿上来和大家讨论。

接下来一篇，给大家看看另外一个很折腾的，网上也找不到太详细方案的VC2022 + protobuf 配置