如何构建交叉编译代码的单元测试？

Question

我的新项目是针对嵌入式ARM处理器。我有一个使用在Ubuntu linux机器上运行的交叉编译器的构建系统。我喜欢尽可能多地使用单元测试，但我对如何进行此设置感到有些困惑。

我无法看到如何在ARM设备上运行单元测试（如果我错了，有人会纠正我）。我认为我最好的选择是使用自己的本机编译器在构建机器上编译代码以进行单元测试。这种方法是否存在根本缺陷？在不同的平台上进行单元测试是浪费时间吗？

我打算在构建机器上使用CppUnit，使用本机编译器进行单元测试。然后我将交叉编译ARM处理器的代码，并在目标设备上进行集成和系统测试。你将如何构建源代码和测试代码以防止这种情况变得混乱？

Answer 1

使用嵌入式设备取决于您拥有的接口（硬件）。

例如我处理的运动控制卡使用命令行界面。他们发布的IDE使用它作为与卡交互的主要方法。无论我使用PCI，IDE，串行还是以太网，它都以相同的方式工作。

他们为编程提供的DLL可以访问命令行界面。所以我可以发送一个字符串，并回读响应。因此，我为单元测试所做的是将一张物理卡挂在（或在）我的开发机器上。我在上传软件后发送命令，读取响应，如果它们是正确的，则通过测试。

我还有额外的硬件，如果你愿意的话，还有一个黑盒子，模拟一个通常连接运动控制卡的机器。它有助于自动化设置，但有一个手动阶段，因为我必须设置开关来模拟机器上的不同设置。

通过使用数字I / O卡并使用输出输入到运动控制卡的输入端并反向输入，我已经实现了更高程度的自动化。

我发现对于大多数硬件，你必须拥有某种类型的模拟器硬件。

例外是软件模拟器附带的罕见软件包。

我知道这不太理想，因为并非每个开发人员都可以在桌面上安装其中一个。我的硬件模拟器，所以我可以把它交给那时工作在运动控制软件上的人。如果它不能携带，那么就可以使用专用的测试或硬件开发计算机。

最后，它归结为硬件的细节以及制造商在软件和模拟器方面提供的支持。为了帮助您，您需要发布更多细节。

Answer 2

在嵌入式行业的十多年里，我已经看到它做了很多方面。在我现在的公司：

• 我们的一款产品具有足够的马力（和空间）来在目标板上进行测试。它有点慢，我们不能把所有的蟒蛇都放在我们想要的盒子上，但效果很好。
• 我们的某个产品没有空间，因此我们编译x86中的所有库（任何与硬件无关的库）并在桌面上运行单元测试。它并不完美，但总比没有好。
• 我们的一个组件是在异国情调的硬件上使用超轻量级的功率管理器，因此几乎不可能进行单元测试。核心算法（DES等）如上所述在x86上进行测试，但是大部分代码只需要在原位进行整体测试。这需要大量的代码审查。