Support some comments before 'package', such as License comment.

I don't know whether the correct way, but can leave the license comment and support the empty line before the 'package' token.Pos. It may be ugly implementation. Please point out if there is a mistake.

Fixes https://github.com/cweill/gotests/issues/37

If the .IsNaked check is in place, the generated code will not compile when the tests are generated for files containing functions which neither accept arguments nor return values (e.g., main()). See Issue 32.

I have added the ability to use custom templates for generating tests. The templates should just be a modified copy of the ones provided in the library. This is useful for us as we would only like to make a few minor modifications for our specific use. There was also demand for it in issues like #5

-template accepts a path to a template folder that is used to generate the test. Allowing people to use their own templates when generating tests

Any tips and feedback welcome!

As the linked travis build demonstrates, the test TestGenerateTests fails with Go 1.10 due to changes to go fmt.

Here's a breakdown of the issue:

• gotests generates a test
• the generated test is then formatted (using Go 1.10 fmt)
• the formatted generated output is compared against the golden files which were formatted using an older version of Go
• They don't match.

The exact formatting problem lies in this block:

I'm still thinking about how to go about this in a clean way.

It can be useful if you write some wrapper function in test file to simplify testing. For example I wrote function that is not pure. And for test it I wrote some wrapper that mock this function environment and call that function multiple times on series of input data. When I was try to generate table test for this wrapper function gotests wan't help me :smile: So I use dirty hack to do it - move wrapper function from test file and back. And now I want better solution like in this PR.

go get -u -v github.com/cweill/gotests/... github.com/cweill/gotests (download)

cd /Users/Project/go/src/github.com/cweill/gotests; git pull --ff-only

There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details.

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream-to=origin/<branch> master

package github.com/cweill/gotests/...: exit status 1

Adding version command to show current version of gotests installed.

NOTE Had issue with tests failing intermittently locally (even on develop). Not sure what the issue, please let me know if this is a known issue or something I should make another ticket for. This only appears to be happening for the 1.16.x build.

#133

Hi, I'm getting the below error while generating tests after upgraded to go1.7. If anything is missing, please help..

panic: inconsistent import: func errors.New(text string) error previously imported as: func errors.New(text string) error [recovered] panic: inconsistent import: func errors.New(text string) error previously imported as: func errors.New(text string) error

goroutine 34 [running]: panic(0x28f460, 0xc4204c94c0) /usr/local/go/src/runtime/panic.go:500 +0x1a1 go/types.(_Checker).handleBailout(0xc4202861c0, 0xc4202f5a18) /usr/local/go/src/go/types/check.go:213 +0xae panic(0x28f460, 0xc4204c94c0) /usr/local/go/src/runtime/panic.go:458 +0x243 go/internal/gcimporter.(_importer).declare(0xc42036f380, 0x49aba0, 0xc4204fdf90) /usr/local/go/src/go/internal/gcimporter/bimport.go:175 +0x17c go/internal/gcimporter.(_importer).obj(0xc42036f380, 0xfffffffffffffffb) /usr/local/go/src/go/internal/gcimporter/bimport.go:203 +0x4a2 go/internal/gcimporter.BImportData(0xc420268690, 0xc4204a9000, 0xb51, 0xe00, 0xc4202ec999, 0x6, 0x0, 0x6, 0xc42005c820, 0xc42005c8f0) /usr/local/go/src/go/internal/gcimporter/bimport.go:88 +0x390 go/internal/gcimporter.Import(0xc420268690, 0xc4202ec999, 0x6, 0xc420288180, 0x3f, 0xc420146a00, 0x0, 0x0) /usr/local/go/src/go/internal/gcimporter/gcimporter.go:166 +0x551 go/importer.gcimports.ImportFrom(0xc420268690, 0xc4202ec999, 0x6, 0xc420288180, 0x3f, 0x0, 0x1, 0x2, 0x0) /usr/local/go/src/go/importer/importer.go:70 +0x67 go/types.(_Checker).collectObjects(0xc4202861c0) /usr/local/go/src/go/types/resolver.go:191 +0x826 go/types.(_Checker).checkFiles(0xc4202861c0, 0xc4204b6300, 0x16, 0x20, 0x0, 0x0) /usr/local/go/src/go/types/check.go:225 +0xaa go/types.(_Checker).Files(0xc4202861c0, 0xc4204b6300, 0x16, 0x20, 0xc4204d0b70, 0xc4202f5a90) /usr/local/go/src/go/types/check.go:218 +0x49 go/types.(_Config).Check(0xc4204cdac0, 0x0, 0x0, 0xc42007f040, 0xc4204b6300, 0x16, 0x20, 0xc4204d4320, 0x0, 0x3, ...) /usr/local/go/src/go/types/api.go:344 +0x1a3 github.com/cweill/gotests/internal/goparser.(_Parser).parseTypes(0xc4202f5eb8, 0xc42007f040, 0xc4204b6300, 0x16, 0x20, 0xc4204a1e00, 0x8) /Users/cfs426/workspace/src/github.com/cweill/gotests/internal/goparser/goparser.go:119 +0x18c github.com/cweill/gotests/internal/goparser.(_Parser).parseFunctions(0xc4202f5eb8, 0xc42007f040, 0xc4200b1080, 0xc4204b6300, 0x16, 0x20, 0x1e98, 0x16, 0x20) /Users/cfs426/workspace/src/github.com/cweill/gotests/internal/goparser/goparser.go:96 +0x74 github.com/cweill/gotests/internal/goparser.(_Parser).Parse(0xc4202f5eb8, 0xc4202880c0, 0x5b, 0xc42025a600, 0x16, 0x20, 0xc420070d80, 0x20, 0x18) /Users/cfs426/workspace/src/github.com/cweill/gotests/internal/goparser/goparser.go:56 +0x2b9 github.com/cweill/gotests.generateTest(0xc4202880c0, 0x5b, 0xc42025a600, 0x16, 0x20, 0xc420230880, 0x0, 0x0, 0x0) /Users/cfs426/workspace/src/github.com/cweill/gotests/gotests.go:100 +0xc3 github.com/cweill/gotests.parallelize.func1(0xc42022a730, 0xc42025a600, 0x16, 0x20, 0xc420230880, 0xc4202896e0, 0xc4202880c0, 0x5b) /Users/cfs426/workspace/src/github.com/cweill/gotests/gotests.go:72 +0xd0 created by github.com/cweill/gotests.parallelize /Users/cfs426/workspace/src/github.com/cweill/gotests/gotests.go:74 +0x140

I wonder if having maps instead of the slice is desired feature for gotests users. I made a simple implementation based on default and testify templates.

Can be checked with next parameters:

gotests -nosubtests -asmap -i   -only ^Func$  /path/demo.go
gotests -asmap  -only  ^Func$  /path/demo.go
gotests -parallel -only  ^Func$  /path/demo.go
gotests -only ^Func$  /path/demo.go

Benefits:

• it wouldn't break current implementation if not provided (arg -asmap).
• it makes tests random (as go maps iterated in random order)

Cons:

• asmap isn't the best name for argument, any ideas of better name?
• tests, I need to write a lot of tests before creating PR, but that's OK, I can spend some time.

Error messages omit the table element name (tt.name), making it difficult (impossible?) to identify which table entry failed. This patch adds the name to the error message.

This fixes reset for render's template load, bug appears only while running tests, when previous one is changing text one (if none of the template* params provided).

Adds tests for output.Option checkers

Also fixes two tests:

1. Undefined Interface - solution fixed golden
2. Entire Directory - solution provide template name (testify).

Current code shows this error

$ go get -u github.com/cweill/gotests/...
go: go.mod file not found in current directory or any parent directory.
	'go get' is no longer supported outside a module.
	To build and install a command, use 'go install' with a version,
	like 'go install example.com/cmd@latest'
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

Hi,

I am trying to create a template that different developers can use from a project repo directly.

I have found a small discussion about having a config file for each project. https://github.com/cweill/gotests/issues/5

I wanted to ask if any steps were taken about it?

Thanks.

Using go get -u github.com/cweill/gotests/... to install would give following error message.

go get: installing executables with 'go get' in module mode is deprecated.
	Use 'go install pkg@version' instead.
	For more information, see https://golang.org/doc/go-get-install-deprecation
	or run 'go help get' or 'go help install'.

Instruction to use go install is added to README for Go version >= 1.17.

Thanks for your contribution. When I am generating test if the function has error then we add a test for wantErr then adds Subtests. But there should be a return statement also and return if wantErr e.g

t.Run(tt.name, func(t *testing.T) {
	got, err := tt.p.Write(tt.args.record)
	if (err != nil) != tt.wantErr {
		t.Errorf("parquetWriter.Write() error = %v, wantErr %v", err, tt.wantErr)
		return
	}
        //////////////////// this return should be added//////////////////////////
	if tt.wantErr {
		return
	}
        //////////////////// this return should be added//////////////////////////
        
       // There is no point checking Subtests if I want error it may create wrong test result
	if got != tt.want {
		t.Errorf("parquetWriter.Write() = %v, want %v", got, tt.want)
	}
})

TL;DR

Raised a PoC PR, and it passed all the checks. If it looks good to you, I can raise a PR in this repository. I will also update the README.md to indicate what's supported.

Why

From Go's release policy:

Each major Go release is supported until there are two newer major releases.

As a result, unless under some special circumstances, I feel that it does not make much sense to support versions that are not even supported by official Go team.

Context

As of now, tests are failing with the following error message:

../../../golang.org/x/tools/internal/typeparams/normalize.go:162:17: u.EmbeddedType undefined (type *types.Interface has no field or method EmbeddedType)

That is because in Go1.10, type *types.Interface has no field or method EmbeddedType.

I also noticed that we have golang.org/x/tools v0.0.0-20191109212701-97ad0ed33101 in our go.mod, and in that version, the whole typeparams directory does not even exist. From the line number in the error message above, the build job seems to use the latest version instead of the one specified in go.mod, and why is that?

The Go version is 1.10 in the job, and modules was introduced in 1.11, and I suspect that the go get ./... simply downloads the latest version because it just does not understand go.mod.

At this timepoint, I figured that maybe it makes more sense to support the latest releases (i.e., 1.17 and so on) instead of making effort to maintain releases that are too old.