Я напишу сначала как делаю это я:
$ mkdir project
$ cd project
$ mkdir -p cmd/prog1 internal pkg
$ go mod init project
При такой структуре, тестирование кода, расположенного в ./internal (и других каталогах, где лежат go файлы с package отличным от main) сводится к вызову:
$ go test ./... -v
Для запуска тестов для main извращаюсь так:
$ go test ./cmd/*
Пример cmd/main_test.go:
package main
import (
"os"
"testing"
)
// Для чего это делать?
// Можно ли как-то запустить Main функцию с аргументами командной строки?
// os.Args = []string{os.Args[0], "-h"} вместо справки по проге, выводит справку по тестированию
func TestMain(m *testing.M) {
os.Exit(m.Run())
}
Правильно ли я понимаю, что Main никак не протестировать? Это в C++ int main(int argc, char** argv), а тут как? Единственный вывод, который я сделал: Main должна содержать 3-5 строк, типа:
func main() {
flags := Flags;
setupFlags(&flags);
flag.Parse();
run(&flags);
}
Еще я через Makefile эту ересь собирать наловчился:
export GO111MODULE=on
build:
for item in cmd/*; do \
go build -v -o "build/$${item##*/}" "$$item/main.go"; \
# можно сборки под разные архитектуры сделать: \
# GOOS=linux GOARCH=amd64 go build -v -o "build/$${item##*/}-linux-amd64" "$$item/main.go"; \
# GOOS=windows GOARCH=amd64 go build -v -o "build/$${item##*/}-win-amd64.exe" "$$item/main.go"; \
# GOOS=darwin GOARCH=amd64 go build -v -o "build/$${item##*/}-darwin-amd64" "$$item/main.go"; \
done
clean:
rm -rf build/*
Тогда можно будет написать тесты. Что я не правильно усвоил?
