Files
kustomize/kustomize/commands/edit/add/flagsandargs_test.go
monopole b9f05dd357 Expose some top level kustomize commands.
The PR exposes some of the top level kustomize commands
(especially `build`) for reuse in other command line tools
(expecially `kubectl`, see #1500).

This PR represents option 3 from the following list of ways
this exposure could be arranged.

1. Expose the commands in the `api` module.

```
REPO/api/go.mod
REPO/api/builtins
REPO/api/commands <- new
REPO/api/...
```

Disadvantage: This would make `api` module depend on cobra.
That's bad for clients that want to depend on the api, but
want to write their own commands at their own version of
cobra.  The `api` module shouldn't depend on UX libraries
like cobra.

2. Expose the commands in their own `commands` module.

They'd appear alongside `api`, e.g. `

```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/commands/go.mod
REPO/commands/build
REPO/commands/edit
REPO/commands/...
```

Advantage: The commands would be consumed by the kustomize
binary and the kubectl binary in the same way.

Disadvantage: The kustomize binary module and the commands
module could evolve separately with their own version
numbers, creating confusion.

3. Expose the commands in the existing `kustomize` module

```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/kustomize/go.mod
REPO/kustomize/main.go
REPO/kustomize/commands/build
REPO/kustomize/commands/edit
REPO/kustomize/commands/...
```

Outside users, e.g. kubectl, could then

```
import sigs.k8s.io/kustomize/kustomize/v3/commands/build
```

and hopefully still get the `main` package
as they do now via:

```
go get sigs.k8s.io/kustomize/kustomize/v3
```

Advantage: 1) The kustomize binary ships at the same version
as the commands - which makes sense as the binary's
_version_ refers to how the CLI operates (command names,
flags, etc.).  This makes it easy to related the version of
a kustomize binary with the version of commands running in
some other CLI binary.  2) The path to the kustomize binary
doesn't change.

Disadvantage: It's an atypical Go module arrangement.
Usually `main` packages live as leaves under a directory
called `cmd` inside a module, rather than at the _top_ of
the module.  This might cause some problems.  If so, we can
go with option 4.

4. Same as 3, but move `main.go` (the `main` package) down one step.

```
REPO/api/go.mod
REPO/api/builtins
REPO/api/...
REPO/kustomize/go.mod
REPO/kustomize/cmd/main.go
REPO/kustomize/commands/build
REPO/kustomize/commands/edit
REPO/kustomize/commands/...
```
2021-02-04 08:35:01 -08:00

142 lines
3.3 KiB
Go

// Copyright 2019 The Kubernetes Authors.
// SPDX-License-Identifier: Apache-2.0
package add
import (
"reflect"
"testing"
"sigs.k8s.io/kustomize/api/filesys"
)
func TestDataValidation_NoName(t *testing.T) {
fa := flagsAndArgs{}
if fa.Validate([]string{}) == nil {
t.Fatal("Validation should fail if no name is specified")
}
}
func TestDataValidation_MoreThanOneName(t *testing.T) {
fa := flagsAndArgs{}
if fa.Validate([]string{"name", "othername"}) == nil {
t.Fatal("Validation should fail if more than one name is specified")
}
}
func TestDataConfigValidation_Flags(t *testing.T) {
tests := []struct {
name string
fa flagsAndArgs
shouldFail bool
}{
{
name: "env-file-source and literal are both set",
fa: flagsAndArgs{
LiteralSources: []string{"one", "two"},
EnvFileSource: "three",
},
shouldFail: true,
},
{
name: "env-file-source and from-file are both set",
fa: flagsAndArgs{
FileSources: []string{"one", "two"},
EnvFileSource: "three",
},
shouldFail: true,
},
{
name: "we don't have any option set",
fa: flagsAndArgs{},
shouldFail: true,
},
{
name: "we have from-file and literal ",
fa: flagsAndArgs{
LiteralSources: []string{"one", "two"},
FileSources: []string{"three", "four"},
},
shouldFail: false,
},
{
name: "correct behavior",
fa: flagsAndArgs{
EnvFileSource: "foo",
Behavior: "merge",
},
shouldFail: false,
},
{
name: "incorrect behavior",
fa: flagsAndArgs{
EnvFileSource: "foo",
Behavior: "merge-unknown",
},
shouldFail: true,
},
}
for _, test := range tests {
if test.fa.Validate([]string{"name"}) == nil && test.shouldFail {
t.Fatalf("Validation should fail if %s", test.name)
} else if test.fa.Validate([]string{"name"}) != nil && !test.shouldFail {
t.Fatalf("Validation should succeed if %s", test.name)
}
}
}
func TestExpandFileSource(t *testing.T) {
fSys := filesys.MakeEmptyDirInMemory()
fSys.Create("dir/fa1")
fSys.Create("dir/fa2")
fSys.Create("dir/readme")
fa := flagsAndArgs{
FileSources: []string{"dir/fa*"},
}
fa.ExpandFileSource(fSys)
expected := []string{
"dir/fa1",
"dir/fa2",
}
if !reflect.DeepEqual(fa.FileSources, expected) {
t.Fatalf("FileSources is not correctly expanded: %v", fa.FileSources)
}
}
func TestExpandFileSourceWithKey(t *testing.T) {
fSys := filesys.MakeEmptyDirInMemory()
fSys.Create("dir/faaaaaaaaaabbbbbbbbbccccccccccccccccc")
fSys.Create("dir/foobar")
fSys.Create("dir/simplebar")
fSys.Create("dir/readme")
fa := flagsAndArgs{
FileSources: []string{"foo-key=dir/fa*", "bar-key=dir/foobar", "dir/simplebar"},
}
fa.ExpandFileSource(fSys)
expected := []string{
"foo-key=dir/faaaaaaaaaabbbbbbbbbccccccccccccccccc",
"bar-key=dir/foobar",
"dir/simplebar",
}
if !reflect.DeepEqual(fa.FileSources, expected) {
t.Fatalf("FileSources is not correctly expanded: %v", fa.FileSources)
}
}
func TestExpandFileSourceWithKeyAndError(t *testing.T) {
fSys := filesys.MakeFsInMemory()
fSys.Create("dir/fa1")
fSys.Create("dir/fa2")
fSys.Create("dir/readme")
fa := flagsAndArgs{
FileSources: []string{"foo-key=dir/fa*"},
}
err := fa.ExpandFileSource(fSys)
if err == nil {
t.Fatalf("FileSources should not be correctly expanded: %v", fa.FileSources)
}
}