Use Ginkgo -- great test runner and the Gomega test matcher is awesome too. Works out of the box also with straight up go test.
That was my solution back in 2015, and is still my solution today....still writing golang. On Mon, May 25, 2020 at 1:52 PM <dnj0...@gmail.com> wrote: > Me too. Running into the same exact situation. > > On Saturday, May 9, 2015 at 9:44:06 PM UTC-7, Davis Ford wrote: >> >> I know this is an ancient thread, but I thought I'd see if anyone has any >> clever tricks for getting around this with unit tests. >> >> I have a package that has a handful of files. In other languages, >> file-scope variables are very useful for tests, as I often declare a list >> of of variables at the top of the test (e.g. the entity under test, as well >> as several other dependencies it needs that I can inject into it to mock >> its behavior, etc.) This is becoming problematic in golang. Many times >> the list of these variables across files is similar -- similar >> dependencies, etc., and I need to new them up for the test, but now they >> collide across test files. >> >> I'm looking at the following possibilities: >> >> * Move the declaration into every test function so they scoped at the >> function, but this just repeats code and becomes very verbose. >> * Put them all in a struct and reference them as fields hanging off the >> global test struct declared in each test file but this is tedious and makes >> the code less clear (IMO) >> * Just rename them to similar but different names in each test file, >> (this is what the OP was talking about doing) >> * Refactor all the code to try to work around this -- untenable >> >> On Thursday, November 18, 2010 at 11:56:38 AM UTC-5, Russ Cox wrote: >>> >>> We spent a long time on this and decided that in Go >>> file boundaries are never relevant, nor is the order of >>> top-level declarations. This makes it nearly trivial to >>> move code between files as makes sense for organization. >>> (The one exception is imports, but making imports work >>> "at a distance" seemed even worse.) >>> >>> I have found myself in the situation you are in on >>> occasion, and I always end up doing one of these: >>> >>> 1. Use a per-package logger variable. >>> If this is just for debugging, that's often fine. >>> >>> 2. Identify what the semantic split of the logging >>> is, and use that in the name. For example, if >>> your package is readers and writers and that's >>> how the logging breaks down, then readLogger >>> and writeLogger seem reasonable. >>> >>> Russ >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/s9ShMsCLuXI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHyzJDPM7AF1pao%2BfhUJahWDzQz2%3Djgbt_2yRrGn_MCPZnz6CQ%40mail.gmail.com.
