在哪里放置单元测试源并暴露内部组件？ [英] Where do I place the Unit Testing source and expose the internal components?

问题描述

我接管了一个通过ATL公开组件的项目。

我看到这个单元测试覆盖的两个主要方面：

• 测试内部组件（可以通过COM公开或不公开）


• 测试外部暴露组件（aka测试暴露的接口）

目前，该项目的所有内部组件单元测试都在解决方案中。它们由预处理器标志启用，该标志用于编译它，并在运行时执行。

从我一直在做的研究，似乎规范是将单元测试放在不同的子项目，并有主要的解决方案供应钩该单元测试访问内部组件。使用此设置，单元测试解决方案将设置对被测试解决方案的依赖。这是真正的规范，还是有很多人在那里将他们的单元测试框架放在被测试的解决方案（aka单元测试不是一个子项目，但相当松散cpps #ifdef 'd out如果未提供预处理器标志）？

目前正在使用的单元测试框架似乎是cppunit，我正在考虑将其切换到gtest，并尝试将一切移动到不同的子项目，但我想以确保从长远来看这些努力是值得的。

我想到的一种方法是 __ declspec 要测试的类，它们只有当预处理器定义指定。然后单独的单元测试子项目将使预处理器告诉主要解决方案暴露内部。我只是不知道这是否是最好的路线。

所以我的问题是：

1. 一个单独的（子）项目，并从将要测试的源代码暴露组件（通过钩子，暴露类定义等）？


2. 组件从COM DLL？


3. 使用 __ declspec 为内部组件测试一个坏主意的预处理器标志？有没有其他人用他们的单元测试这样做，正在测试的项目在正常操作期间通常不暴露？

感谢您的意见！

解决方案

另一个团队的人说他们的团队将所有的单元测试放在单独的项目中，静态库。这对我很有意义，因为它有助于模块化，并提供了许多其他的好处。因此，每个主要的代码耦合将是一个静态的库（不过于舷外;））和每个静态库，你将有一个单独的单元测试解决方案。然后你的主DLL变成一个薄包装器暴露必要的项目。

因此解决方案如下所示：

MainSolution b
$ b

• ProjCommonLib


• ProjExportsLib


• ProjImportsLib


• ProjOtherStuffLib


• COMDLL-Proj


• UnitTestsFolder
  
  
  
  • ProjCommonLibTests
  
  
  • ProjExportsLibTests
  
  
  • ProjImportsLibTests
  
  
  • ProjOtherStuffLibTests
  
  
  • COMDLL -ProjTests
  
  

这种类型的设置允许单元测试静态库和完全访问的内部，而不必处理__declspec。这看起来很干净，因为DLL没有任何性能打击模块化，因为其他库只是那些，静态库。

我把它放置为回答，看看它是否得到任何投票（aka，这个答案是一个很好的方法，是我做得很好）。如果这是一个坏的解决方案，请张贴你的答案。

I am taking over a project that exposes components via ATL.

I see two major areas for the unit test to cover with this setup:

• Testing the internal components (may or may not be exposed via COM)
• Testing the external exposed components (aka testing the exposed interface)

Currently the project has all of its internal components unit tests inside of the solution. They are enabled by a preprocessor flag that compiles it in and executes when you run.

From the research I have been doing, it appears that the "norm" is to place the unit testing in a different sub project and to have the main solution supply hooks for the unit tests to access internal components. With this setup, the unit testing solution would set a dependency to the solution being tested. Is this truly the "norm", or are there a lot of people out there that place their unit testing framework inside of the solution that is being tested (aka unit test is not a sub project but rather loose cpps that are #ifdef'd out if the preprocessor flag is not supplied)?

It appears that the unit testing framework currently in use is cppunit and I was thinking of switching it over to gtest and trying to move everything into a different sub project but I want to make sure the effort will be worth it in the long run.

One way I thought of was to __declspec the classes to be tested and they are only exposed when the preprocessor define is specified. Then the separate unit test sub project would enable that preprocessor to tell the main solution to expose the inners. I am just not sure if this is the best route.

So my questions are:

1. Is the norm to place unit tests in a separate (sub)project and expose the components from the source that will be tested (either via hooks, exposing the class definition, etc)?
2. What is the best way to expose the internal components from a COM DLL?
3. Would a preprocessor flag that enables __declspec for the internal components to be tested a bad idea? Has anyone else done this with their unit tests where the item being tested is not normally exposed during normal operation?

Thanks for the comments!

解决方案

Someone on another team said that their team placed all of the unit tests in separate projects and were able to expose the internals via static libs. This makes a lot of sense to me in that it helps with modularity and provides alot of other benefits. So each major coupling of code would be a static lib (without going too overboard ;) ) and for each static lib, you would have a separate unit test solution. Then your main DLL becomes a thin wrapper that exposes the necessary items.

So the solution would look like:

MainSolution

• ProjCommonLib
• ProjExportsLib
• ProjImportsLib
• ProjOtherStuffLib
• COMDLL-Proj
• UnitTestsFolder
  • ProjCommonLibTests
  • ProjExportsLibTests
  • ProjImportsLibTests
  • ProjOtherStuffLibTests
  • COMDLL-ProjTests

This type of setup allows the unit tests to set dependencies on the static lib and have full access to the internals without ever having to deal with __declspec. This seems a lot cleaner because the DLL doesn't have any performance hit with the modularity because the other libraries are just that, static libraries.

I am placing this as an "answer" to see if it gets any up votes (aka, "this answer is a good approach and is what I do as well"). If this is a bad solution please post your answers.

这篇关于在哪里放置单元测试源并暴露内部组件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！