我正在尝试在 Go 中为现有服务实现单元测试，该服务使用连接池结构和来自现有库的连接结构(调用这些 LibraryPool 和 LibraryConnection) 连接到外部服务。 为了使用这些，主代码中的服务函数使用池的一个唯一的全局实例，它有一个 GetConnection() 方法，如下所示:

// Current Main Code
var pool LibraryPool // global, instantiated in main()

func someServiceFunction(w http.ResponseWriter, r *http.Request) {
  // read request
  // ...
  conn := pool.GetConnection()
  conn.Do("some command")
  // write response
  // ... 
}

func main() {
  pool := makePool() // builds and returns a LibraryPool
  // sets up endpoints that use the service functions as handlers
  // ...
}

我想在不连接到外部服务的情况下对这些服务功能进行单元测试，因此我想模拟 LibraryPool 和 LibraryConnection。为此，我正在考虑将主要代码更改为如下内容:

// Tentative New Main Code
type poolInterface interface {
  GetConnection() connInterface
}

type connInterface interface {
  Do(command string)
}

var pool poolInterface

func someServiceFunction(w http.ResponseWriter, r *http.Request) {
  // read request
  // ...
  conn := pool.GetConnection()
  conn.Do("some command")
  // write response
  // ...
}

func main() {
  pool := makePool() // still builds a LibraryPool
}

在测试中，我将使用这些接口(interface)的模拟实现 MockPool 和 MockConnection，全局 pool 变量将使用 模拟池。我将在 TestMain() 内的 setup() 函数中实例化这个全局 pool功能。

问题是在新的主代码中，LibraryPool 没有正确实现poolInterface，因为GetConnection() 返回 connInterface 而不是 LibraryConnection(即使 LibraryConnection 是 connInterface 的有效实现)。

进行此类测试的好方法是什么？顺便说一句，主要代码也很灵活。

最佳答案

好吧，我会尝试通过完整解释我如何看待这个设计来回答。如果这太多而不是重点，请提前道歉..

• 实体/域
  • 应用程序的核心，将包含实体结构，不会导入任何外层包，但每个包都可以导入(几乎)
• 应用程序/用例
  • “服务”。将主要负责应用程序逻辑，不知道传输(http)，将通过接口(interface)与数据库“对话”。您可以在此处进行域验证，例如，如果找不到资源或文本太短。与业务逻辑相关的任何内容。
• 运输
  • 将处理 http 请求、解码请求、让服务执行他的工作并对响应进行编码。如果请求中缺少必需的参数，或者用户未被授权，或者其他原因，您可以在这里返回 401...
• 基础设施
  • 数据库连接
  • 也许是一些 http 引擎和路由器之类的东西。
  • 完全与应用程序无关，不导入任何内部包，甚至不导入 Pseron

例如，假设我们想做一些像将人插入数据库一样简单的事情。

包 person 将只包含 person 结构

package person

type Person struct{
  name string
}

func New(name string) Person {
  return Person{
    name: name,
  {
}

关于数据库，假设你使用sql，我建议制作一个名为sql的包来处理repo。 (如果你使用 postgress，请使用'postgress package ...)。

personRepo 将获取将在 main 中初始化的 dbConnection 并实现 DBAndler。只有连接会直接与数据库“对话”，存储库的主要目标是成为数据库的网关，并以应用程序的方式说话。 (连接与应用无关)

package sql

type DBAndler interface{
  exec(string, ...interface{}) (int64, error)
}

type personRepo struct{
  dbHandler DBHandler
}

func NewPersonRepo(dbHandler DBHandler) &personRepo {
  return &personRepo{
    dbHandler: dbHandler,
  }
}

func (p *personRepo) InsertPerson(p person.Person) (int64, error) {
  return p.dbHandler.Exec("command to insert person", p)
}

服务将在初始化程序中将此存储库作为依赖项(作为接口(interface))获取，并将与其交互以完成业务逻辑

package service

type PersonRepo interface{
  InsertPerson(person.Person) error
}

type service struct {
  repo PersonRepo
}

func New(repo PersonRepo) *service {
  return &service{
    repo: repo
  }
}

func (s *service) AddPerson(name string) (int64, error) {
  person := person.New(name)
  return s.repo.InsertPerson(person)
}

您的传输处理程序将使用作为依赖项的服务进行初始化，并且他将处理 http 请求。

package http

type Service interface{
  AddPerson(name string) (int64, error)
}

type handler struct{
  service Service
}

func NewHandler(s Service) *handler {
  return &handler{
    service: s,
  }
}

func (h *handler) HandleHTTP(w http.ResponseWriter, r *http.Request) {
  // read request
  // decode name

  id, err := h.service.AddPerson(name)

  // write response
  // ... 
}

在 main.go 中你会把所有东西联系在一起:

1. 初始化数据库连接
2. 使用此连接初始化 personRepo
3. 使用 repo 初始化服务
4. 使用服务初始化传输

主要包

func main() {
  pool := makePool()
  conn := pool.GetConnection()

  // repo
  personRepo := sql.NewPersonRepo(conn)

  // service
  personService := service.New(personRepo)

  // handler
  personHandler := http.NewPersonHandler(personService)

  // Do the rest of the stuff, init the http engine/router by passing this handler.

}

请注意，每个包结构都使用 interface 初始化，但返回一个 struct，并且接口(interface)是在使用它们的包中声明的，而不是在使用它们的包中声明的实现它们。

这使得对这些包进行单元测试变得容易。例如，如果您想测试服务，则无需担心 http 请求，只需使用一些实现服务所依赖的接口(interface)(PersonRepo)的“模拟”结构，就可以了。

好吧，我希望它对你有一点帮助，一开始它可能看起来很困惑，但你很快就会发现这看起来像是一大段代码，但当你需要添加功能或切换db 驱动程序等。我建议您阅读 go 中的域驱动设计，以及六角拱。

编辑:

此外，通过这种方式您传递到服务的连接，服务不会导入和使用全局数据库池。老实说，我不知道为什么它如此普遍，我想它有它的优点并且对某些应用程序更好，但一般来说我认为让你的服务依赖于某个接口(interface)，而不真正知道发生了什么，是很多更好的做法。

关于unit-testing - 当A的方法在Go中返回B时模拟对象A和B，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53769424/