我们有一个文件IO库，它基本上以精美的格式将数据写入文件，然后再读回文件。即使库（或计算机）在写入过程中崩溃，我们也必须确保文件是可读的。
我们知道如何编写一个崩溃的程序。我们可以使用kill(getpid())来模拟崩溃。或者我们可以使用1/0等等。因此，我们将编写一个程序来打开库，写入一些数据，然后在中间自行杀死。然后我们有一个半成品状态的文件，我们可以在阅读器中打开，看看读者是否可以处理该文件。
问题：如何使其自动化？
例如，我们喜欢我们的单元测试套件（它自动测试库的许多方面并给出通过/失败）来创建一个新的程序/进程，开始编写文件然后自杀。然后可以将控制权交还给单元测试，然后可以打开seppuku之前创建的进程文件。然后单元测试可以对文件进行一些验证，看看我们是否满足了我们的要求＆＃34;在崩溃时保留有效文件＆＃34;。
我正在调查exec函数，它似乎正在做我们需要的东西。但是，如果exec＆＃39; d程序崩溃，我无法确定exec是否返回给调用方程序/进程。
答案 0 :(得分：1)
我有一个＆＃34; testrunner.cpp＆＃34;对于我的编译器项目，它完全能够处理编译器和生成的测试代码崩溃（不幸的是，在开发过程中，你会发现当你做错了任何事情时，这两件事都会发生。编译器或测试代码本身的代码错误 - 或两者兼得！）。它非常简单，它使用标准库函数system来创建一个新进程。
您当然也可以使用fork后跟exec，然后使用waitpid或其他wait类型函数来获取结果。 system本质上就是这样，但它也启动了一个shell，所以你可以很容易地使用重定向（我的＆＃34; testrunner.cpp＆＃34;确实如此）。
system（或wait）将返回已执行程序的结果代码。就我而言，任何＆＃34;非零＆＃34;结果被视为失败（我真的不在乎为什么失败 - 一切都应该通过！），但你可能需要检查＆＃34;它是否崩溃或正常结束＆＃34;在你的代码中。
我的＆＃34; testrunner.cpp＆＃34;可以在这里找到（它是运行测试的完整代码，除了编译器和＆＃34; diff＆＃34; - 当然要使用它，你还需要在同一目录中的测试源）： https://github.com/Leporacanthicus/lacsap/blob/master/test/testrunner.cpp
特别是runcmd是调用system的地方。
答案 1 :(得分：1)
这是一种开箱即用的想法 - 建议的替代方法来进行测试。
如果您的测试应该确定主程序如何处理因崩溃而截断的文件，那么更确定的测试方法是获取有效文件的副本，并使用truncate()截断它
或ftruncate()然后运行您的主程序。您甚至可以对从0到完整大小的文件大小进行测试。
如果你担心你可能有前20个KiB是某些新文件内容的第一部分，但另外30个KiB（为了论证）是先前版本的剩余部分，那么你需要工作稍微努力，但你仍然可以确定性地生成这样的文件，然后在故意生成的损坏文件上运行你的主程序。