测试编译代码返回预期输出/错误的最佳方法
如何测试编译后的代码是否返回预期输出或按预期失败？
我在下面制定了一个工作示例，但它不容易扩展。每个额外的测试都需要额外的嵌套括号。当然，我可以将其拆分为其他文件，但是您对如何改进它有什么建议吗？另外，我计划在 makefile 中使用 make test 节中的这个内容，所以我不希望其他人安装默认情况下未安装的东西，只是为了测试它。标准输出也应该与标准错误保持交错。
简化示例：
./testFoo || echo execution failed
./testBar && echo expected failure
(./testBaz && (./testBaz 2>&1 | cmp -s - foo.tst && ( ./testFoo && echo and so on
|| echo testFoo's execution failed )|| echo testBaz's does not match )
|| echo testBaz's execution failed
我当前的测试仪如下所示（对于一个测试）：
\#!/bin/bash
compiler1 $1 && (compiler2 -E --make $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') && (./$(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') || echo execution failed) || less $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/').err) || echo compile failed
How do you test if compiled code returns the expected output or fails as expected?
I have worked out a working example below, but it is not easily extendable. Every additional test would require additional nesting parentheses. Of course I could split this into other files, but do you have any suggestions on how to improve this?. Also I'm planning to use this from make test stanza in a makefile, so I do not expect other people to install something that isn't installed by default, just for testing it. And stdout should also remain interleaved with stderr.
simplified example:
./testFoo || echo execution failed
./testBar && echo expected failure
(./testBaz && (./testBaz 2>&1 | cmp -s - foo.tst && ( ./testFoo && echo and so on
|| echo testFoo's execution failed )|| echo testBaz's does not match )
|| echo testBaz's execution failed
my current tester looks like this (for one test):
\#!/bin/bash
compiler1 $1 && (compiler2 -E --make $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') && (./$(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') || echo execution failed) || less $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/').err) || echo compile failed
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议从这里开始寻找模式。例如，您可以使用文件名作为模式，然后创建一些对预期结果进行编码的附加文件。
然后，您可以使用简单的脚本来运行命令并验证结果（而不是一次又一次地重复测试代码）。
例如，内容为
0的文件testFoo.exec意味着它必须成功（或至少返回 0），而testBar.exec将包含1。然后，
textBaz.out将包含预期的输出。您不需要多次调用 testBaz；您可以在第一次调用中重定向输出，然后查看$?来查看调用是否成功。如果是，那么您可以直接验证输出（无需再次启动命令）。I suggest to start looking for patterns here. For example, you could use the file name as the pattern and then create some additional files that encode the expected result.
You can then use a simple script to run the command and verify the result (instead of repeating the test code again and again).
For example, a file
testFoo.execwith the content0means that it must succeed (or at least return with 0) whiletestBar.execwould contain1.textBaz.outwould then contain the expected output. You don't need to call testBaz several times; you can redirect the output in the first call and then look at$?to see if the call succeeded or not. If it did, then you can directly verify the output (without starting the command again).我自己简单的测试工具的工作原理如下：
每个测试都由扩展名为 .test 的 bash 脚本表示 - 这些都位于同一目录中
当我创建测试时，我运行测试脚本并检查输出
仔细地，如果它看起来不错，它会进入一个名为 good_results 的目录，在一个与生成它的测试同名的文件中
主测试脚本找到所有 .test 脚本并依次执行每个脚本，生成一个临时输出文件。这与
good_results 目录中的匹配文件以及报告的任何差异
Itv 花了我大约半个小时来编写此文件并使其正常工作，但事实证明它是无价的！
My own simple minded test harness works like this:
every test is represented by a bash script with an extension .test - these all live in the same directory
when I create a test, I run the test script and examine the output
carefully, if it looks good it goes into a directory called good_results, in a file with the same name as the test that generated it
the main testing script finds all the .test scripts and executes each of them in turn, producing a temporary output file. This is diff'd with the
matching file in the good_results directory and any differences reported
Itv took me about half an hour to write this and get it working, but it has proved invaluable!