Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests #1

Open
matt-FFFFFF opened this issue Jan 10, 2023 · 2 comments
Open

Tests #1

matt-FFFFFF opened this issue Jan 10, 2023 · 2 comments

Comments

@matt-FFFFFF
Copy link

Just had a meeting with @grayzu and have opened this issue for discussion, though happy to discuss internally if required.

See the lz-vending module - it uses Terratest and AzApi.

However the module is split into three sub modules, the test packages are organized accordingly. There is also an integration test package to test the orchestration (root) module.

When performing unit tests I use the go list idea that Hashicorp uses in its test framework. See the Makefile.

Unless an env variable is set the e2e tests do not run - again this comes from on the Hashicorp model for azurerm.

The test func names are Test for unit tests and TestDeploy for e2e. Could we use something similar? It allows us to filter the tests by name in the go test command. Again see Makefile.

/cc @jtracey93

@lonegunmanb
Copy link
Contributor

Thanks for rasing this good question @matt-FFFFFF ! I've submitted a new pr for this codex to add new regulations for the test go code. Basically we would put e2e, upgrade and unit test codes in different folders with different package, we can filter the tests we want by executing the following command in test folder:

$ go test -v -timeout=120m ./e2e
$ go test -v -timeout=120m ./upgrade
$ go test -v ./unit 

Does that work for you?

@matt-FFFFFF
Copy link
Author

Hi @lonegunmanb

I think I could make this work, yes. I still think the go list approach is more flexible, with a filter and well-defined test func names. Like so:

TEST?=$$(go list ./... |grep -v 'vendor'|grep -v 'utils')
TESTTIMEOUT=10m

test-e2e:
  cd tests  
  go test $(TEST) -run ^TestE2E -timeout $(TESTTIMEOUT)

test-unit:
  cd tests  
  go test $(TEST) -run ^TestUnit -timeout $(TESTTIMEOUT)

Params can then be overridden on the command line, e.g.

make test-e2e TESTTIMEOUT=60m

However your solution works and I could re-organize my module like so:

In the test dir I could have:

.
├── e2e
│   ├── integration.go
│   ├── submodule1.go
│   └── submodule2.go
├── unit
│   ├── integration.go
│   ├── submodule1.go
│   └── submodule2.go
└── upgrade
    └── upgrade.go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants