-
Notifications
You must be signed in to change notification settings - Fork 64
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
Move integration tests to integration
package
#2009
Conversation
@@ -0,0 +1,20 @@ | |||
package internal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I find "internal" not very descriptive. "helpers" or "utils" or "setuputil" would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can move it to a package inside internal
. We do need the internal
nesting because it means it can only be imported by other packages inside integration
. See https://go.dev/doc/go1.4#internalpackages
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Test Details: go/deco-tests/12317614117 |
One additional test skip in the last commit. Merging without waiting for another integration test run. |
// TestMain is the entrypoint executed by the test runner. | ||
// See [internal.Main] for prerequisites for running integration tests. | ||
func TestMain(m *testing.M) { | ||
internal.Main(m) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pietern we might want to re-think this - it turns out having TestMain disables go test's built-in caching, which could be useful in speeding up test runs both locally and on CI.
## Changes This PR adds back debugging functionality that was lost during migration to `internal.Main` as an entry point for integration tests. The PR that caused the regression: #2009. Specifically the addition of internal.Main as the entrypoint for all integration tests. ## Tests Manually, by trying to debug a test.
## Changes - Remove TestMain from integration tests and related checks. - This fixes "go test" caching for integration tests. The test_main.go files were added in #2009 to make sure integration tests are not run as part of go test ./.... We recommend running make test to run tests, which includes the packages to test (and excludes integration). ## Tests To test that caching works I ran a test twice: ``` + CLOUD_ENV=aws + go test --timeout 3h -v -run TestDefaultPython/3.9 ./integration/bundle/ … PASS ok github.com/databricks/cli/integration/bundle (cached) ```
Changes
Objectives:
go test ./...
TestAcc
test name prefixThe tree structure generally mirrors the source code tree structure.
Requirements for new files in this directory:
_test
appendedmain_test.go
file.These requirements are enforced by a unit test in the
integration
package.Tests
Integration tests pass.
The total run time regresses by about 10%. A follow-up change that increases the degree of test parallelism will address this.