代码之家 › 专栏 › 技术社区 › LiraNuna

编译器错误的单元测试

error-handling unit-testing c++

LiraNuna · 技术社区 · 15 年前

class ErrorTest
{
    OtherClass& read_write() {
        return other;
    }

    const OtherClass& read_only() const {
        return other;
    }

    private:
        OtherClass other;
};

ErrorTest test;
OtherClass other = test.read_only();
test.read_write() = other.modify();
test.read_only() = other.modify(); /* This should error */

4 回复 | 直到 15 年前

Chris Arguin 15 年前

我想现在的主要问题是,你现在是在测试你的代码还是编译器?

测试编译器不一定是件坏事。。。我在过去遇到过编译器升级掩码错误,因此最好确保您得到与预期相同的安全检查集。

一个稍微简单一点的方法可能是保留一个坏代码目录,让脚本一次编译一个文件。在那里有一个“#ifdef MAKEFAIL”标志,用于打开应该失败的确切条件。确保编译器在未设置该标志时返回0,在设置该标志时返回非零。假设编译器在失败时返回非零。。。我不知道MSVC是否遵循这个规则。

为了解决可移植性问题,我将抛出的第三个选项是autoconf。设置起来可能很痛苦,但其部分目的是确保在编译之前拥有一个健全的开发环境。您可以在其中添加一个这样的测试,它可以让您找到编译器并进行尝试。

Tim Sylvester 15 年前

这似乎有点像在*nix机器上从源代码对构建进行“/configure”时发生的自动检测。autoconf脚本构建小程序并尝试编译它们,以确定编译器支持的可用程序。

重用其中的任何一个可能都不实际,但您可能需要相同的模型。每个测试都有自己的文件或一组文件,以及一个单独的项目文件/maketarget/等。。然后,您的测试脚本将尝试生成每个测试用例,并通过grep或将输出与存储在测试用例中的基线输出进行比较,检查是否发生了预期的错误。

Jared Oberhaus 15 年前

但是在这种情况下,您真正需要的是一个静态分析工具,它检查以确保您的开发人员编写的代码遵循这样的约定。这当然是一个有效的构建工具。但是,搜索静态分析工具来查找您在这里指定的内容可能很困难。我从维基百科的文章开始 List of tools for static code analysis ,在 C/C++ 节。

请注意,您编写的代码不是“错误”,它只是您的约定。这是一个非常好的约定,但编译器不应该也不应该约束您遵守该约定。静态分析工具也不应如此。因此,您需要找到一个允许您配置什么是允许的,什么是不允许的。

Isaac Pascual 5 年前

std::is_const< decltype( std::declval<ErrorTest>().read_only() ) >::value

推荐文章

mg610 · 如何开始C++单元测试

2 年前

dezox · 如何对Active Directory对象创建进行单元测试?

2 年前

Phil Gunning · 使用嵌套函数更改进行模拟测试

2 年前

Asa LeHolland · 是否有一种pythonic单元测试方法来断言函数已成功导入?

2 年前

shilin agre · 在Python中测试修饰函数

2 年前

SlipScout · Unittest只传递单个值,而不是获取多个值

2 年前

EconNoob · JUnit5在预期另一种异常时获取NullPointerException

2 年前

Kristesiashvili · 如果不能捕获源代码中的更改,那么用mock编写单元测试有什么意义呢?

2 年前

Alex · 从实际对象的实例返回默认模拟结果

2 年前

Ehsan Akbar · 掠夺客户例外。数据库DatabaseDoesNotExistException:'数据库'*****'不存在

2 年前