假设我有一个简单的应用程序,可以从stdin读取行并将其回显到stdout。例如:
package main
import (
"bufio"
"fmt"
"io"
"os"
)
func main() {
reader := bufio.NewReader(os.Stdin)
for {
fmt.Print("> ")
bytes, _, err := reader.ReadLine()
if err == io.EOF {
os.Exit(0)
}
fmt.Println(string(bytes))
}
}
我想编写一个测试案例,该案例写入stdin,然后将输出与输入进行比较。例如:
package main
import (
"bufio"
"io"
"os"
"os/exec"
"testing"
)
func TestInput(t *testing.T) {
subproc := exec.Command(os.Args[0])
stdin, _ := subproc.StdinPipe()
stdout, _ := subproc.StdoutPipe()
defer stdin.Close()
input := "abc\n"
subproc.Start()
io.WriteString(stdin, input)
reader := bufio.NewReader(stdout)
bytes, _, _ := reader.ReadLine()
output := string(bytes)
if input != output {
t.Errorf("Wanted: %v, Got: %v", input, output)
}
subproc.Wait()
}
跑步go test -v
给我以下内容:
=== RUN TestInput
--- FAIL: TestInput (3.32s)
echo_test.go:25: Wanted: abc
, Got: --- FAIL: TestInput (3.32s)
FAIL
exit status 1
我显然在这里做错了什么。我应该如何测试这种类型的代码?
这是一个写入stdin并从stdout读取的示例。请注意,它不起作用,因为输出首先包含“>”。不过,您可以对其进行修改以适合您的需求。
func TestInput(t *testing.T) {
subproc := exec.Command("yourCmd")
input := "abc\n"
subproc.Stdin = strings.NewReader(input)
output, _ := subproc.Output()
if input != string(output) {
t.Errorf("Wanted: %v, Got: %v", input, string(output))
}
subproc.Wait()
}
问题内容: 一切在命令行上都可以正常运行,但是当我将所需的内容转换为Java时,接收过程在stdin上什么都收不到。 这是我所拥有的: 脚本“ count-the-bytes”很简单: 输出表明该函数挂在’wc -c’行-永远不会到达’counted stdin bytes’行。 这是怎么回事?使用Jsch会有所帮助吗? 问题答案: 您可能希望在wc -c返回之前尝试关闭输出流。
问题内容: 我正在尝试编写一个Python脚本来启动一个子进程,并将其写入子进程stdin。我还希望能够确定子进程崩溃时要采取的措施。 我试图启动的过程是一个名为的程序nuke,它具有自己的Python内置版本,我希望能够向其提交命令,然后告诉其在命令执行后退出。到目前为止,我已经得出结论,如果我在类似这样的命令提示符下启动Python,然后作为子进程启动,那么我可以在中键入命令,但是我希望能够将
问题内容: 是否有合法的方式写下我打算以后编写完整测试功能的测试用例?就像即将进行的mochajs测试一样? 问题答案: 软件包文档使用以下示例描述了这样的示例: 如果不适用于调用 T和 B的Skip方法,则可以跳过测试和基准测试: 如果您启动带有标志的消息,则将打印您提供的消息(在此示例中,您还需要提供标志以查看跳过消息)。
问题内容: 我正在为Java编程竞赛编写一些代码。程序的输入是使用stdin给出的,输出是在stdout上给出的。你们如何测试可在stdin / stdout上运行的程序?这就是我的想法: 由于System.in的类型为InputStream,而System.out的类型为PrintStream,因此我使用以下原型在函数中编写了代码: 现在,我想使用junit对此进行测试。我想使用字符串伪造Sys
如 Serverless Framework 官方所说 虽然 Serverless 架构在服务业务逻辑方面引入了很多简单性,但是它的一些特性给测试带来了挑战。他们是: Serverless 架构是独立的分布式服务的集成,它们必须被独立地和一起地测试。 Serverless 架构依赖于互联网、云服务,这些服务很难在本地模拟。 Serverless 架构可以具有事件驱动的异步工作流程,这些工作流程很难
如果现有的特征测试不能完成你所需要的工作,你就必须编写一个新的。这些宏是创建模块。它们为其它宏提供了检查各种 特征是否存在并且报告结果的方式。 本章包括一些建议和一些关于现有的测试的为什么要那样编写的原因。通过阅读现有的测试,你还可以学到许多关于编写 Autoconf测试的方法。如果在一个或多个Autoconf测试中出现了错误,这些信息可以帮助你理解它们意味着什么,这有助 于你找到最佳的解决问题的