15

我习惯于试驾我的代码。现在我是 Go 的新手，我正试图尽快把它弄好。我正在使用标准库中的测试包，这似乎已经足够好了。（我也喜欢它不是另一个外部依赖项。与任何 Java 或 Ruby 项目相比，我们目前总共有 2 个依赖项......）无论如何 - 它看起来像 golang 中的断言看起来像这样：

func TestSomething(t *testing.T) {
  something := false
  if something {
    t.Log("Oh noes - something is false")
    t.Fail()      
  }
}

我觉得这很冗长，并想在一行上做：

Assert( something, "Oh noes - something is false" )

或类似的东西。我希望我在这里错过了一些明显的东西。最好/惯用的方法是什么？

更新：只是为了澄清。如果我要做这样的事情：

func AssertTrue(t *testing.T, value bool, message string) {
  if value {
    t.Log(message)
    t.Fail()
  }
}

然后像这样写我的测试

func TestSomething(t *testing.T) {
  something := false
  AssertTrue(t, something, "Oh noes - something is false")
}

那么这不是最好的方法吗？

4

4 回答 4

17

有可以与股票测试框架集成的外部包。

我很久以前写的其中一个gocheck旨在对这种用例进行排序。

有了它，测试用例看起来像这样，例如：

func (s *Suite) TestFoo(c *gocheck.C) {
    // If this succeeds the world is doomed.
    c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
}

您可以像往常一样使用 运行它go test，并且该检查中的失败将报告为：

----------------------------------------------------------------------
FAIL: foo_test.go:34: Suite.TestFoo

all_test.go:34:
    // If this succeeds the world is doomed.
    c.Assert("line 1\nline 2", gocheck.Equals, "line 3")
... obtained string = "" +
...     "line 1\n" +
...     "line 2"
... expected string = "line 3"

请注意代码正上方的注释如何包含在报告的故障中。

还有许多其他常用功能，例如套件和特定于测试的设置和拆卸例程等。请查看网页了解更多详情。

它维护得很好，因为我和其他人在许多活动项目中使用它，所以请随时加入，或跟进并检查其他更适合您口味的类似项目。

有关 gocheck 使用的示例，请查看诸如mgo、goyaml、goamz、pipe、vclock、juju（大量代码库）、lpad、gozk、goetveld、tomb等包。还有 gocheck ，设法进行自我测试。引导它非常有趣。

于 2013-09-05T14:19:27.617 回答
1

但是当你尝试像马丁叔叔那样编写测试时，在测试中使用一个断言和长函数名，那么简单的断言库，如http://github.com/stretchr/testify/assert可以让它更快更容易

于 2013-09-07T09:35:20.910 回答
0

我不鼓励以您似乎渴望的方式编写测试。整个 stdlib 使用您所说的“冗长”方式并非偶然。

不可否认，它的行数更多，但这种方法有几个优点。

如果您阅读了为什么 Go 没有断言？s/error handling/test failure reporting/g您可以了解为什么用于 Go 测试的几个“断言”包不是一个好主意，

再次证明，stdlib 的庞大代码库。

于 2013-09-05T13:46:30.120 回答
-1

惯用的方式是您上面的方式。此外，如果您不希望，您不必记录任何消息。

正如 GO FAQ所定义的：

为什么 Go 没有断言？

Go 不提供断言。不可否认，它们很方便，但我们的经验是，程序员将它们用作拐杖，以避免考虑正确的错误处理和报告。正确的错误处理意味着服务器在非致命错误后继续运行而不是崩溃。正确的错误报告意味着错误是直截了当的，使程序员免于解释大量的崩溃跟踪。当看到错误的程序员不熟悉代码时，精确的错误尤为重要。

我们知道这是一个争论点。Go 语言和库中有很多与现代实践不同的地方，仅仅是因为我们觉得有时值得尝试不同的方法。

更新
根据您的更新，这不是惯用的 Go。您所做的实质上是设计一个测试扩展框架来反映您在 XUnit 框架中获得的内容。虽然从工程的角度来看，根本没有什么错误，但它确实引发了关于维护这个扩展库的价值 + 成本的问题。此外，您正在创建一个可能会激怒羽毛的内部标准。Go 最大的特点是它不是 C、Java、C++ 或 Python，应该按照语言的构造方式来做。

于 2013-09-05T13:45:33.000 回答