在哪里存储测试（项目结构 - 最佳实践）？答案

【问题标题】：Where store Tests (project structure - best practice)?在哪里存储测试（项目结构 - 最佳实践）？
【发布时间】：2020-04-14 10:15:52
【问题描述】：

我们有许多不同的方式来在 GO 中实现项目结构。

我的问题是存储测试实现的最佳方式：

单独（作为Java Maven/Gradle 标准）

├── pkg
│   ├── colocator
│   │   ├── some_impl.go
│   │   └── ...
│   ├── common
│   │   └── ...
│   └── dashboard
│       └── ...
├── test
│   │  └── internal
│   │      └── some_test_utils.go
│   ├── pkg
│   │   ├── colocator
│   │   │   ├── mocks
│   │   │   │   └── some_mock.go
│   │   │   └── some_impl_test.go
│   │   ├── ...

到位

├── pkg
│   ├── colocator
│   │   ├── mocks
│   │   │   └── some_mock.go
│   │   ├── some_impl.go
│   │   └── some_impl_test.go

等等……

【问题讨论】：

对包 A 的测试存储在包 A 的文件夹中。在 Go 中，您不使用模拟（在 Java 或 PHP 的意义上）。看看 Go 标准库是如何组织的。
那么模拟接口（自己或使用外部库）呢？
我尝试使用 Clean Architecture 方法 => 我必须创建和实现接口，我必须在测试中模拟接口
这似乎是对必须使用模拟的清洁架构的常见误解。你没有。请了解测试替身的所有变体。再次：看一下stdlib；它几乎不使用任何模拟。
如果你读过任何关于 Go 测试的文章，你会发现推荐总是第二个选项。第一个选项只允许对公共 API 进行黑盒测试，您无法测试任何未导出的内容。

标签： go project-structure clean-architecture django-project-architect go-testing

【解决方案1】：

您的第二个实现是“正确”的方式。此外，您不必担心那些测试占用空间或其他东西。编译包时编译器会忽略。

【讨论】：

谢谢。但我想验证组织项目最方便的方式是什么