w*******a
发帖数: 21 | 1 很恶心， 公司要求写unit testing code.
class X
{
...
public:
void foo()
{
...
abc_.doSomething();
}
private :
ABC abc_; // created in constructor of X
Node * p;
}
1)如果我要测试class X 的 foo(), 但是 abc_ 并没有作为 passed in a parameter
in function foo(), how could i pass a mocked class ABC instance to
replace abc_?
2) 另外就是假若我测试 foo()的时候， foo() 的执行取决于 X class 前面执行已经建立的状态 state. 我测试的时候如何模拟这个状态的成立？ 比如 X class has a linked list Node *p, when foo() is executed, the linked list should have | X****r
发帖数: 3557 | 2 单元测试是一个很好的习惯，我的看法是凡是对最终产品有贡献的代码
都必须有单元测试。被测试的单元应该有着尽可能清晰的界面，你最终
会发现这样的设计会导致更灵活的代码，即使不是为了测试而是将来的
代码重构也是有利的。
你这里的情况有两种可能的解决方向。如果foo这个函数和X的其他成员
耦合程度很高的话，你可以着重于测试foo所提供的功能，就像实际的
使用者一样来使用foo，包括调用X的其他函数（它们本身也被其他单元
测试所覆盖），从而确定foo的正确性。比如：
void XTest::testFoo() {
X x;
// setup x here.
x.foo();
// assert the state of x here.
}
另一方面，如果foo这个函数本身相对独立的话，你可以把它的实现作
为一个不依赖于X的其他成员的函数分出来，这样这个实现函数就可以
被单独测试：
class X {
public:
void foo() { fooImpl(abc_, p); }
private:
ABC abc_;
Node * p;
void
【在 w*******a 的大作中提到】
: 很恶心， 公司要求写unit testing code.
: class X
: {
: ...
: public:
: void foo()
: {
: ...
: abc_.doSomething();
: }
| w*******a
发帖数: 21 | 3 楼主讲得很清晰, 看来经验很丰富。谢谢
不过我感觉有时候为了测试而把程序结构变得 反而不是很合理, 就像你所说的建立一
个私有的constructor to set up reference or pointer of abc.
【在 X****r 的大作中提到】
: 单元测试是一个很好的习惯，我的看法是凡是对最终产品有贡献的代码
: 都必须有单元测试。被测试的单元应该有着尽可能清晰的界面，你最终
: 会发现这样的设计会导致更灵活的代码，即使不是为了测试而是将来的
: 代码重构也是有利的。
: 你这里的情况有两种可能的解决方向。如果foo这个函数和X的其他成员
: 耦合程度很高的话，你可以着重于测试foo所提供的功能，就像实际的
: 使用者一样来使用foo，包括调用X的其他函数（它们本身也被其他单元
: 测试所覆盖），从而确定foo的正确性。比如：
: void XTest::testFoo() {
: X x;
| d****p
发帖数: 685 | 4 基本思路是加编译开关 -- 测试关联的代码在发布时可以很容易地被关掉
【在 w*******a 的大作中提到】
: 楼主讲得很清晰, 看来经验很丰富。谢谢
: 不过我感觉有时候为了测试而把程序结构变得 反而不是很合理, 就像你所说的建立一
: 个私有的constructor to set up reference or pointer of abc.
|
|
