如何为已删除的默认构造函数编写测试

How to write a test for a deleted default constructor

本文关键字：构造函数 测试 默认 删除      更新时间：2023-10-16

我有一个类A，我删除了默认构造函数。

class A {
public:
A() = delete;
A(int a): m_myInt(a) {}
private:
const int m_myInt;
};
int main () {
A foo(1);  // works perfect
A bar;   // won't compile
}

如何编写一个好的单元测试，确保A bar;仍然无效？我可以编写一个不编译的测试，并将编译错误作为测试要求。我想知道，是否有更好的方法来编写单元测试？

2)如果std::is_trivially_constructible<T>::value为真，则提供等于true的成员常量值，否则值false。

http://en.cppreference.com/w/cpp/types/is_default_constructible

依赖于确认某些代码构造无法编译的单元测试没有错。 单元测试的目的是确定代码的一个或多个部分是否集体"适合使用"，并且标准可以表示功能或非功能(例如质量)属性。 如果"适合使用"标准是"代码将无法编译，如果....."那么一个明显的方法是编写一个单元测试，故意寻求导致编译失败。

对于编译器来说，这当然是一种有效的单元测试方法 - 在这种方法中，测试编译器如何响应错误代码示例是完全适合作为单元测试或单元测试集的。

鉴于要求是A的默认实例化(用OP的话来说)"仍然无效"，通过单元测试的基本标准将是执行的代码编译失败

A bar;

根据要求，此类代码可能需要在不同的上下文中进行测试(例如，在作为A成员或朋友的检测函数中，在不相关的函数中，在文件范围内等)。 因此，此要求可能需要一组单元测试。

要实现这样的测试，构建过程必须捕获编译是否失败。 成功的编译需要捕获为失败的测试，相反，失败的编译需要捕获为通过的单元测试。

根据需要捕获多少证据来证明单元测试通过(或失败)的声明的合理性，生成过程可能需要捕获和分析编译器诊断 - 例如，确定源文件中的哪些行实际上导致编译失败。

同样，可能需要一个单元测试或一组单元测试来检查某些代码结构是否编译。

你可以为此使用特征：

static_assert(!std::is_constructible<A>::value, "!");
相关文章：