steve/databricks-cli
steve
/
databricks-cli
mirror of https://github.com/databricks/cli.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
databricks-cli/integration/cmd/unknown_command_test.go

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

19 lines
490 B
Go
Raw Normal View History

Move integration tests to `integration` package (#2009) ## Changes Objectives: * A dedicated directory for integration tests * It is not picked up by `go test ./...` * No need for a `TestAcc` test name prefix * More granular packages to improve test selection (future) The tree structure generally mirrors the source code tree structure. Requirements for new files in this directory: * Every package **must** be named after its directory with `_test` appended * Requiring a different package name for integration tests avoids aliasing with the main package. * Every integration test package **must** include a `main_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.
2024-12-13 14:38:58 +00:00
package cmd_test
Add regression tests for CLI error output (#1566) ## Changes Add regression tests for https://github.com/databricks/cli/issues/1563 We test 2 code paths: - if there is an error, we can print to stderr - if there is a valid output, we can print to stdout We should also consider adding black-box tests that will run the CLI binary as a black box and inspect its output to stderr/stdout. ## Tests Unit tests
2024-07-10 06:38:06 +00:00
import (
Remove calls to `t.Setenv` from integration tests (#2018) ## Changes The `Setenv` helper function configures an environment variable and resets it to its original value when exiting the test scope. It is incompatible with running tests in parallel because it modifies process-wide state. The `libs/env` package defines functions to interact with the environment but records `Setenv` calls on a `context.Context`. This enables us to override/specialize the environment scoped to a context. Pre-requisites for removing the `t.Setenv` calls: * Make `cmdio.NewIO` accept a context and use it with `libs/env` * Make all `internal/testcli` functions use a context The rest of this change: * Modifies integration tests to initialize a context to use if there wasn't already one * Updates `t.Setenv` calls to use `env.Set` ## Tests n/a
2024-12-16 11:34:37 +00:00
"context"
Add regression tests for CLI error output (#1566) ## Changes Add regression tests for https://github.com/databricks/cli/issues/1563 We test 2 code paths: - if there is an error, we can print to stderr - if there is a valid output, we can print to stdout We should also consider adding black-box tests that will run the CLI binary as a black box and inspect its output to stderr/stdout. ## Tests Unit tests
2024-07-10 06:38:06 +00:00
"testing"
Move the CLI test runner to `internal/testcli` package (#2004) ## Changes The CLI test runner instantiates a new CLI "instance" through `cmd.New()` and runs it with specified arguments. This is as close as we get to running the real CLI **in-process**. This runner was located in the `internal` package next to other helpers. This change moves it to its own dedicated package. Note: this runner transitively imports pretty much the entire repository, which is why we intentionally keep it _separate_ from `testutil`. ## Tests n/a
2024-12-12 16:48:51 +00:00
"github.com/databricks/cli/internal/testcli"
Add regression tests for CLI error output (#1566) ## Changes Add regression tests for https://github.com/databricks/cli/issues/1563 We test 2 code paths: - if there is an error, we can print to stderr - if there is a valid output, we can print to stdout We should also consider adding black-box tests that will run the CLI binary as a black box and inspect its output to stderr/stdout. ## Tests Unit tests
2024-07-10 06:38:06 +00:00
assert "github.com/databricks/cli/libs/dyn/dynassert"
)
func TestUnknownCommand(t *testing.T) {
Remove calls to `t.Setenv` from integration tests (#2018) ## Changes The `Setenv` helper function configures an environment variable and resets it to its original value when exiting the test scope. It is incompatible with running tests in parallel because it modifies process-wide state. The `libs/env` package defines functions to interact with the environment but records `Setenv` calls on a `context.Context`. This enables us to override/specialize the environment scoped to a context. Pre-requisites for removing the `t.Setenv` calls: * Make `cmdio.NewIO` accept a context and use it with `libs/env` * Make all `internal/testcli` functions use a context The rest of this change: * Modifies integration tests to initialize a context to use if there wasn't already one * Updates `t.Setenv` calls to use `env.Set` ## Tests n/a
2024-12-16 11:34:37 +00:00
ctx := context.Background()
stdout, stderr, err := testcli.RequireErrorRun(t, ctx, "unknown-command")
Add regression tests for CLI error output (#1566) ## Changes Add regression tests for https://github.com/databricks/cli/issues/1563 We test 2 code paths: - if there is an error, we can print to stderr - if there is a valid output, we can print to stdout We should also consider adding black-box tests that will run the CLI binary as a black box and inspect its output to stderr/stdout. ## Tests Unit tests
2024-07-10 06:38:06 +00:00
assert.Error(t, err, "unknown command", `unknown command "unknown-command" for "databricks"`)
assert.Equal(t, "", stdout.String())
assert.Contains(t, stderr.String(), "unknown command")
}