测试用例VS ASSERTION语句 [英] Test Cases VS ASSERTION statement

问题描述

在我最多的C ++项目中，我大量使用ASSERTION语句如下：

  int doWonderfulThings（const int * fantasticData）
 {
 ASSERT（fantasticData）; 
 if（！fantasticData）
 return -1; 
 // ,,, 
 return WOW_VALUE; 
} 
  

但是TDD社区似乎喜欢做这样的事情：

  int doMoreWonderfulThings（const int * fantasticData）
 {
 if（！fantasticData）
 return ERROR_VALUE; 
 // ... 
 return AHA_VALUE; 
} 
 
 TEST（TDD_Enjoy）
 {
 ASSERT_EQ（ERROR_VALUE，doMoreWonderfulThings（0L））; 
 ASSERT_EQ（AHA_VALUE，doMoreWonderfulThings（Foo））; 
} 
  

只要我的经验第一个方法让我删除这么多微妙的错误。
但是TDD方法是处理旧代码的非常聪明的想法。

Google - 他们将第一方法与 ，游泳海洋没有任何安全防护。

哪一个更好？
哪一个使软件健壮？

解决方案在我的（有限的）体验第一个选项是一个更安全。在测试用例中，只测试预定义的输入并比较结果，只要检查了每个可能的边缘情况，这就可以很好地工作。第一个选项只是检查每个输入，因此测试活值，它会快速过滤出错误，但是会带来性能损失。

在代码完成史蒂夫·麦康奈尔向我们学习了第一种方法可以成功地用来过滤掉调试构建。在发布版本中，您可以过滤所有断言（例如使用编译器标志）以获得额外的性能。

在我看来，最好的方法是使用两种方法：

方法1捕获非法值

  int doWonderfulThings int * fantasticData）
 {
 ASSERT（fantasticData）; 
 ASSERTNOTEQUAL（0，fantasticData）
 
 return WOW_VALUE / fantasticData; 
} 
  

和方法2来测试算法的边缘情况。

  int doMoreWonderfulThings（const int fantasticNumber）
 {
 int count = 100; 
 for（int i = 0; i  count + = 10 * fantasticNumber; 
} 
 return count; 
} 
 
 TEST（TDD_Enjoy）
 {
 //测试下边沿
 ASSERT_EQ（0，doMoreWonderfulThings（-1））; 
 ASSERT_EQ（0，doMoreWonderfulThings（0））; 
 ASSERT_EQ（110，doMoreWonderfulThings（1））; 
 
 //测试一些随机值
 ASSERT_EQ（350，doMoreWonderfulThings（5））; 
 ASSERT_EQ（2350，doMoreWonderfulThings（15））; 
 ASSERT_EQ（225100，doMoreWonderfulThings（150））; 
} 
  

In my most C++ project I heavily used ASSERTION statement as following:

int doWonderfulThings(const int* fantasticData)
{
    ASSERT(fantasticData);
    if(!fantasticData)
        return -1;
    // ,,,
    return WOW_VALUE;
}

But TDD community seems like to enjoy doing something like this:

int doMoreWonderfulThings(const int* fantasticData)
{
    if(!fantasticData)
        return ERROR_VALUE;
    // ...
    return AHA_VALUE;
}

TEST(TDD_Enjoy)
{
    ASSERT_EQ(ERROR_VALUE, doMoreWonderfulThings(0L));
    ASSERT_EQ(AHA_VALUE, doMoreWonderfulThings("Foo"));
}

Just with my experiences first approaches let me remove so many subtle bugs. But TDD approaches are very smart idea to handle legacy codes.

"Google" - they compare "FIRST METHOD" to "Walk the shore with life-vest, swim ocean without any safe guard".

Which one is better? Which one makes software robust?

解决方案

In my (limited) experience the first option is quite a bit safer. In a test-case you only test predefined input and compare the outcome, this works well as long as every possible edge-case has been checked. The first option just checks every input and thus tests the 'live' values, it filters out bugs real quickly, however it comes with a performance penalty.

In Code Complete Steve McConnell learns us the first method can be used successfully to filter out bugs in a debug build. In release build you can filter-out all assertions (for instance with a compiler flag) to get the extra performance.

In my opinion the best way is to use both methods:

Method 1 to catch illegal values

int doWonderfulThings(const int* fantasticData)
{
    ASSERT(fantasticData);
    ASSERTNOTEQUAL(0, fantasticData)

    return WOW_VALUE / fantasticData;
}

and method 2 to test edge-cases of an algorithm.

int doMoreWonderfulThings(const int fantasticNumber)
{
    int count = 100;
    for(int i = 0; i < fantasticNumber; ++i) {
        count += 10 * fantasticNumber;
    }
    return count;
}

TEST(TDD_Enjoy)
{
    // Test lower edge
    ASSERT_EQ(0, doMoreWonderfulThings(-1));
    ASSERT_EQ(0, doMoreWonderfulThings(0));
    ASSERT_EQ(110, doMoreWonderfulThings(1));

    //Test some random values
    ASSERT_EQ(350, doMoreWonderfulThings(5));
    ASSERT_EQ(2350, doMoreWonderfulThings(15));
    ASSERT_EQ(225100, doMoreWonderfulThings(150));
}

这篇关于测试用例VS ASSERTION语句的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！