c496921d44
Issue #10659 lists a number of extra linting checks that we could enable in order to make our Go code more robust. This commit implements as many as seem sensible: * `durationcheck`, which checks for multiplication of `time.Duration`s, which can lead to unexpected behaviour (e.g. `time.Second * time.Second` is *not* one second) * `goprintffuncname`, which checks that `Printf`-like functions are appropriately suffixed with `f` to indicate as such * `tenv`, which checks for `os.Setenv` in tests where `t.Setenv` is generally a better solution * `wastedassign`, which checks for assignments whose values are never used (such as initial values before an `if` where both branches then overwrite the value) * `whitespace`, which checks for blank lines at the beginning and end of blocks such as functions, `if`s, `for`s and so on. This commit does *not* enable the following checks listed in #10659: * `wrapcheck`, which insists that third-party library errors are always `%w`rapped -- we have a lot of cases where we don't do this and it's probably a bit more involved than "just wrap them" in terms of making sure we don't break anything (maybe) * `predeclared`, which checks for shadowing of existing Go identifiers -- we use `old` and `new` a lot, especially in step generation, so this is probably a slightly bigger clean-up/one we might want to opt out of * `mnd` (magic number detection) -- we have a lot of failures on this * `nilnil` -- we only have a couple of failures on this; these could probably be handled with `//nolint` but for now I've opted not to take this route. |
||
---|---|---|
.. | ||
README.md | ||
helpers.go | ||
program_driver.go | ||
program_driver_test.go | ||
sdk_driver.go | ||
testdata | ||
type_driver.go |
README.md
SDK Codegen Tests
TestSDKCodegen runs the complete set of SDK code generation tests against a particular language's code generator. It also verifies that the generated code is structurally sound.
The test files live in pkg/codegen/testing/test/testdata
and
are registered in the following globals in pkg/codegen/testing/test.
- sdk_driver.go:
PulumiPulumiSDKTests
- program_driver.go:
PulumiPulumiProgramTests
- program_driver.go:
PulumiPulumiYAMLProgramTests
An SDK code generation test files consists of a schema and a set of expected outputs for each language. Each test is structured as a directory that contains that information:
testdata/
my-simple-schema/ # i.e. `simple-enum-schema`
schema.(json|yaml)
go/
python/
nodejs/
dotnet/
...
The schema is the only piece that must be manually authored.
Once the schema has been written, the actual codegen outputs can be
generated by running the following in pkg/codegen
directory:
PULUMI_ACCEPT=true go test ./...
This will rebuild subfolders such as go/
from scratch and store
the set of code-generated file names in go/codegen-manifest.json
.
To generate the code for a specific directory in testdata,
run the following instead:
PULUMI_ACCEPT=true go test ./... -run TestGenerate/$dirName
If these outputs look correct, they need to be checked into git and will then serve as the expected values for the normal test runs:
$ go test ./...
That is, the normal test runs will fail if changes to codegen or
schema lead to a diff in the generated file set. If the diff is
intentional, it can be accepted again via PULUMI_ACCEPT=true
.
Writing Program Tests on Generated Code
To support running unit tests over the generated code, the tests
also support mixing in manually written $lang-extras
files into
the generated tree. For example, given the following input:
testdata/
my-simple-schema/
schema.json
go/
go-extras/
tests/
go_test.go
The system will copy go-extras/tests/go_test.go
into
go/tests/go_test.go
before performing compilation and unit test
checks over the project generated in go
.