-3

We have many different ways to implement project structure in GO.

My question is where the best way to store tests implementation:

  1. separately (as Java Maven/Gradle standard)

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

  2. in place

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

  3. etc...

?

kozmo
  • 4,024
  • 3
  • 30
  • 48
  • 1
    Test for package A are store in the folder of package A. In Go you do not use mocks (in the sense of Java or PHP). Take a look at how the Go stdlib is organized. – Volker Apr 14 '20 at 10:42
  • And what about mocking interfaces (self or use external libs)? – kozmo Apr 14 '20 at 11:20
  • I try to use `Clean Architecture` approach => I have to crete and implement interfaces and I have to mock ones in tests – kozmo Apr 14 '20 at 11:25
  • 1
    This seems to be a common misunderstanding of Clean Architecture that you have to use mocks. You don't. Please learn about all variants of test doubles. Again: Take a look at the stdlib; it uses almost no mocks. – Volker Apr 14 '20 at 12:08
  • 1
    If you read anything about Go testing, you'll find the recommendation is always the second option. The first option would only allow for black-box testing of public API, you couldn't test anything unexported. – Adrian Apr 14 '20 at 13:06
  • @Agrian - How could I testing complex `composition` without mocks? – kozmo Apr 14 '20 at 13:41

1 Answers1

2

Your second implementation is the 'correct' go way. Also you dont have to worry about those tests taking up space or something. The compiler ignores when you build the package.

A_kat
  • 1,459
  • 10
  • 17