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 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/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com.
