如何获取“RedirectStandardOutput”在 NUnit 工作?
我正在为我们的 QA 小组制定自动化策略,并且需要能够捕获脚本和 EXE 文件的输出。当我作为控制台应用程序运行此代码时,我能够成功捕获 plink.exe 的输出:
class Program
{
static void Main(string[] args)
{
Process process = new Process();
process.StartInfo.FileName = @"C:\Tools\plink.exe";
process.StartInfo.Arguments = @"10.10.9.27 -l root -pw PASSWORD -m C:\test.sh";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
string output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
output = output.Trim().ToLower(); // Output is successfully captured here
if (output == "pass")
{
Console.WriteLine("Passed!");
}
}
}
此命令大约需要一分钟才能执行,我成功地将结果捕获到输出变量。
但是,当我将相同的代码编译为 DLL 并通过 NUnit 运行时,代码立即完成并失败,输出值 == NULL:
[TestFixture]
public class InstallTest
{
[Test]
public void InstallAgentNix()
{
Process process = new Process();
process.StartInfo.FileName = @"C:\Tools\plink.exe";
process.StartInfo.Arguments = @"10.10.9.27 -l root -pw PASSWORD -m C:\test.sh";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
string output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
output = output.Trim().ToLower();
Assert.AreEqual("pass", output, "Agent did not get installed");
}
}
我已将问题范围缩小到行 string output = process.StandardOutput。 ReadToEnd()。如果我注释掉该行,执行时间约为一分钟,并且该操作在远程计算机上成功执行(test.sh 在远程 Linux 机器上执行)。
我希望我错过了一些简单的东西 - 我不想找到不同的测试工具。
它看起来类似于这里的(未解决的)问题:为什么在 DLL 文件中启动的进程在使用控制台应用程序测试时可以工作,但在被另一个 DLL 文件调用时却不能工作?
I am working on an automation strategy for our QA group and need to be able to capture the output of scripts and EXE files. When I run this code as a console application, I am able to successfully capture the output of plink.exe:
class Program
{
static void Main(string[] args)
{
Process process = new Process();
process.StartInfo.FileName = @"C:\Tools\plink.exe";
process.StartInfo.Arguments = @"10.10.9.27 -l root -pw PASSWORD -m C:\test.sh";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
string output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
output = output.Trim().ToLower(); // Output is successfully captured here
if (output == "pass")
{
Console.WriteLine("Passed!");
}
}
}
This command takes about a minute to execute and I successfully capture the results to the output variable.
However, when I compile the same code as a DLL and run through NUnit, the code completes immediately and fails with the value of output == NULL:
[TestFixture]
public class InstallTest
{
[Test]
public void InstallAgentNix()
{
Process process = new Process();
process.StartInfo.FileName = @"C:\Tools\plink.exe";
process.StartInfo.Arguments = @"10.10.9.27 -l root -pw PASSWORD -m C:\test.sh";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();
string output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
output = output.Trim().ToLower();
Assert.AreEqual("pass", output, "Agent did not get installed");
}
}
I have narrowed the problem down to the line string output = process.StandardOutput.ReadToEnd()
. If I comment the line out, execution time is around a minute and the operation is successfully executed on the remote machine (test.sh gets executed on a remote Linux box).
I hope I'm missing something simple - I don't want to have to find a different test harness.
It looks similar to the (unsolved) question here: Why does a process started in a DLL file work when tested using console application, but not when called by another DLL file?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好吧,我花了一晚上的时间,但我想通了。除了重定向标准输出之外,我还必须 RedirectStandardInput 才能正常工作。
以下是在 DLL 文件中运行的固定代码。仅供参考,此修复也解决了 Windows 窗体应用程序中的问题:
OK, it took me all night but I figured it out. I have to RedirectStandardInput in addition to redirecting standard output for this to work.
Here is the fixed code that works in a DLL file. As an FYI, this fix resolves the problem in a Windows Forms application as well:
正如您自己发现的那样,添加该行
可以解决问题。 NUnit 必须设置另一个间接级别。感谢您自己的回答,使我免于痛苦的调查。
虽然我不认为问题来自 DLL 文件/EXE 文件之间的差异,因为我在编译为控制台应用程序的测试项目中遇到了这个问题。
As you found by yourself, adding the line
solves the problem. NUnit must set up another level of indirection. Thanks for your own answer which saved me from painful investigation.
Although I don't think the issue comes from the difference between DLL file/EXE file since I encountered this in a test project compiled as a console application.