Go单元测试编写的五个建议 - HelloWorld开发者社区

测试驱动开发是保持高代码质量的好方法，同时保护自己免于回归，并向自己和其他人证明自己的代码完成了预期的工作。这里有五个技巧和窍门可以改善你的测试。

把你的测试放在一个不同的包里

Go坚持同一个文件夹中的文件属于同一个包，除了_test.go文件。将测试代码移出软件包，可以让您编写测试，就好像您是软件包的真正用户。你不能摆弄内部，而是专注于暴露的界面，并总是想着你可能会添加到你的API的任何噪音。
Go单元测试编写的五个建议
这样可以让你自由地更改内部，而无需调整测试代码。

在不同的文件中进行内部测试

如果你确实需要对一些内部进行单元测试，用_internal_test.go作为后缀创建另一个文件。内部测试必然比接口测试更脆弱，但是它们是确保内部组件行为的一个很好的方法，而且如果你使用测试驱动开发的话，它是特别有用的。

Go单元测试编写的五个建议

运行所有测试保存

去建立和运行速度非常快，所以没有任何理由可以说为什么不每次保存时都运行整个测试case。

当你在这个时候，为什么不去同时运行go vet，golint和goimports呢？

在Sublime Text中，这可以通过安装GoSublime并在添加以下配置项之前按下 Cmd +.,5来实现：

“on_save”: [{
  “cmd”: “gs9o_run_many”, “args”: {
    “commands”:[
      [“clear”],
      [“sh”, “if [ -f onsave.sh ]; then ./onsave.sh; else gofmt -s -w ./ && go build . errors && go test -i && go test && go vet && golint ; fi”]
    ],
    “focus_view”: false
  }
}],
“fmt_cmd”: [“goimports”]

上面的脚本首先检查项目是否有一个onsave.sh文件，它会运行。这使您可以轻松关闭不适用的软件包的自动测试功能。

写表驱动的测试

匿名结构和复合文字允许我们写出非常清晰和简单的表格测试，而不依赖任何外部包。下面的代码允许我们为一个尚未写成的“Fib”函数设置一系列的测试：

var fibTests = [] struct { 
  n int // input 
  expected int //预期结果
} { 
  {1,1}，
  {2,1}，
  {3,2}，
  {4,3}，
  {5,5}，
  {6，8}，
  {7，13}，
}

然后，我们的测试函数只是覆盖在切片上，在声明结果正确之前为每个“n”调用“Fib”方法：

func TestFib(t *testing.T) {
  for _, tt := range fibTests {
    actual := Fib(tt.n)
    if actual != tt.expected {
      t.Errorf("Fib(%d): expected %d, actual %d", tt.n, tt.expected, actual)
    }
  }
}

看看你是否可以自己写“Fib”函数来让测试通过，或者你可以从Dave Chaney那里找到解决方法。

使用Go代码模拟接口

如果你需要模拟你的代码依赖的东西来正确地测试它，那么很可能是一个接口的好选择。即使你依赖于一个你不能改变的外部包，你的代码仍然可以使用一个外部类型将会满足的接口。

经过几年的写mocks接口，我终于找到了模拟接口的完美方式，而不需要添加任何依赖项到我们的项目中： [check out Moq](https://medium.com/@matryer/meet-moq-easily-mock-interfaces-in-go-476444187d10)。

假设我们正在导入这个外部包：

package mailman
import “net/mail”
type MailMan struct{}
func (m *MailMan) Send(subject, body string, to ...*mail.Address) {
  // some code
}
func New() *MailMan {
  return &MailMan{}
}

如果我们正在测试的代码需要一个MailMan对象，我们的测试代码可以调用它的唯一方法是提供一个实际的MailMan实例。

func SendWelcomeEmail（m * MailMan，to ... * mail.Address）{...}

这意味着每当我们运行我们的测试，一个真正的电子邮件可以发送。想象一下，如果我们已经实现了上面的保存功能。我们很快就会惹恼我们的测试用户，或者拿出一大笔服务费用。另一种方法是将这个简单的接口添加到您的代码中：

type EmailSender interface{
  Send(subject, body string, to ...*mail.Address)
}

当然，MailMan已经满足了这个接口，因为我们首先从他的Send方法签名 - 所以我们仍然可以像以前一样传入MailMan对象。但现在我们可以写一个测试邮件发件人：

type testEmailSender struct{
  lastSubject string
  lastBody    string
  lastTo      []*mail.Address
}
// make sure it satisfies the interface
var _ package.EmailSender = (*testEmailSender)(nil) 
func (t *testEmailSender) Send(subject, body string, to ...*mail.Address) {
  t.lastSubject = subject
  t.lastBody = body
  t.lastTo = to
}

现在我们可以更新我们的SendWelcomeEmail函数来取接口，而不是具体的类型：

func SendWelcomeEmail（m EmailSender，to ... * mail.Address）{...}

在我们的测试代码中，我们可以发送我们的假发送者，并在调用目标函数之后在这些字段上进行断言：

func TestSendWelcomeEmail(t *testing.T) {
  sender := &testEmailSender{}
  SendWelcomeEmail(sender, to1, to2)
  if sender.lastSubject != "Welcome" {
    t.Error("Subject line was wrong")
  }
  if sender.To[0] != to1 && sender.To[1] != to2 {
    t.Error("Wrong recipients")
  }
}

如果你想进一步探索mock特性，那么一定要看看check out Moq，它不仅描述了一个写模拟的好方法，而且还为你写。