Another motivation I have heard used is that an os.Exit() from main
by-passes defer(). So if you need to use defer from a "main-like" context
move it to a function called from main(), do your defer(s) in it and then
do the os.Exit() from main()..
On Friday 16 February 2024 at 01:23:57 UTC-8 Mar
My main acts just like a mini bootstrap to do as less as possible and hand
the real action over to start.Run()
But is is still testable.
```
var mainRunner = runner
/* -- Methods/Functions -- */
// runner starts the application and can be overwritten
On Thursday 15 February 2024 at 00:08:44 UTC Jerry Londergaard wrote:
If code is outside of the main function but still in the main package, it
seems its testable like other functions?
Yes indeed.
I suspect though if one is putting tests in package main_test, then I guess
you can't import t
Hi Jerry,
On Wed, 2024-02-14 at 15:31 -0800, Jeremy French wrote:
> I really think the testability issue is the biggest one.
On Wednesday, February 14, 2024 at 7:37:11 PM UTC-5 Dan Kortschak wrote:
With a Main() int, you can use e.g.
https://pkg.go.dev/github.com/rogpeppe/go-internal/tests
On Wed, 2024-02-14 at 15:31 -0800, Jeremy French wrote:
> I really think the testability issue is the biggest one. Generally,
> testing the main package iscumbersome at least. So it's
> reasonable to say, "I'm not going to test the main package, but I
> will keep it so simple that it is impos
On Thursday 15 February 2024 at 10:31:40 am UTC+11 Jeremy French wrote:
I really think the testability issue is the biggest one. Generally,
testing the main package iscumbersome at least. So it's reasonable to
say, "I'm not going to test the main package, but I will keep it so simple
th
I really think the testability issue is the biggest one. Generally,
testing the main package iscumbersome at least. So it's reasonable to
say, "I'm not going to test the main package, but I will keep it so simple
that it is impossible for a bug to exist in there." Then everything else
in
On Wednesday 14 February 2024 at 10:23:37 pm UTC+11 Mike Schinkel wrote:
I cannot speak for others but I can tell you why I keep my `main()` small:
1. I prefer to put as much logic into reusable packages as I can, and
`main()` is not reusable outside the current app.
This is understandable.
I cannot speak for others but I can tell you why I keep my `main()` small:
1. I prefer to put as much logic into reusable packages as I can, and
`main()` is not reusable outside the current app.
2. CLI packages like Viper are configured to be invoked with just one or a
few small commands in `ma
