【发布时间】:2009-06-23 22:39:21
【问题描述】:
我已经开始将我的测试编写为我想要测试的类中的静态函数。这些函数通常测试功能,它们创建大量对象、测量内存消耗(以检测泄漏)等。
这是好的还是坏的做法?从长远来看它会咬我吗?
【问题讨论】:
标签: c++ unit-testing
我已经开始将我的测试编写为我想要测试的类中的静态函数。这些函数通常测试功能,它们创建大量对象、测量内存消耗(以检测泄漏)等。
这是好的还是坏的做法?从长远来看它会咬我吗?
【问题讨论】:
标签: c++ unit-testing
我将它们分开,因为我不希望将测试类包含在可部署的工件中。增加 .exe 的大小或将它们提供给客户是没有意义的。
我建议使用 CppUnit 编写单元测试。
【讨论】:
不,你应该改写unit tests。
【讨论】:
我会说这不是最佳实践,但它“没问题”,因为它不会破坏您的程序或导致它崩溃。有很多事情可以做,但你不应该做。
【讨论】:
测试代码在所有权、部署、非功能性需求等方面与生产代码有着根本的不同。因此,最好将其与正在测试的代码分开,放在单独的文件中,甚至可能放在单独的目录中。
为了方便对被测类进行白盒单元测试,您通常需要将测试类/测试函数声明为友元。某些类仅对公共成员进行单元测试,因此并不总是需要添加朋友。
组合测试代码和被测代码很简单:您只需将目标文件链接到同一个项目中。
有时您会看到 #includes 被测代码的单元测试代码,但我建议您不要这样做 - 例如,如果您有测试覆盖率测量工具(强烈推荐!),这些措施将不会对被测代码正确。
【讨论】:
如果你的类中有测试用例,就很难有固定装置之类的东西。
我还要向Boost.Test 大声疾呼。学习曲线有点高,但是一旦你习惯了它就会很棒。
【讨论】:
这是不好的做法。
您应该有一个单独的类来测试您正在创建的类。你正在做的方式是用测试代码膨胀生产代码。这不是你应该做的。
你想测试类Foo的方式是这样的:
//Foo.cpp
class Foo {
public:
int GetInt() { return 15; }
};
//FooTest.cpp
TEST(FooTest, testGetIntShouldReturn15) {
Foo foo;
ASSERT_EQUAL(15, foo.GetInt());
}
【讨论】: