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

Fake Client does not create error for invalid projects #2314

Closed
prietyc123 opened this issue Oct 23, 2019 · 8 comments
Closed

Fake Client does not create error for invalid projects #2314

prietyc123 opened this issue Oct 23, 2019 · 8 comments

Comments

@prietyc123
Copy link
Contributor

[kind/bug]

What versions of software are you using?

  • Operating System: macOS
  • Output of odo version: master branch

Any logs, error output, etc?

When I ran odo project create DEMO through the CLI I got the error message whereas when I ran through fake client unit test it does not occur.

Outputs

CLI:

$oc new-project DEMO
The ProjectRequest "DEMO" is invalid: metadata.name: Invalid value: "DEMO": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')
$odo project create DEMO
 ✗  ProjectRequest.project.openshift.io "DEMO" is invalid: metadata.name: Invalid value: "DEMO": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

Fake Client:

GOROOT=/usr/local/Cellar/go/1.13.1/libexec #gosetup
GOPATH=/Users/pkumari/go #gosetup
/usr/local/Cellar/go/1.13.1/libexec/bin/go test -c -o /private/var/folders/g8/f12mz2jj1ygbsq8v51fz7dvr0000gn/T/___TestCreate_in_github_com_openshift_odo_pkg_project -gcflags "all=-N -l" github.com/openshift/odo/pkg/project #gosetup
/usr/local/Cellar/go/1.13.1/libexec/bin/go tool test2json -t /Applications/GoLand.app/Contents/plugins/go/lib/dlv/mac/dlv --listen=localhost:52065 --headless=true --api-version=2 exec /private/var/folders/g8/f12mz2jj1ygbsq8v51fz7dvr0000gn/T/___TestCreate_in_github_com_openshift_odo_pkg_project -- -test.v -test.run ^TestCreate$ #gosetup
API server listening at: 127.0.0.1:52065
=== RUN   TestCreate
=== RUN   TestCreate/Case_1:_project_name_is_given
<nil>
=== RUN   TestCreate/Case_2:_no_project_name_given
no project name given
=== RUN   TestCreate/Case_3:_Invalid_project_name_is_given
<nil> # Project name for the test was 'PROJECT'
--- FAIL: TestCreate (0.01s)
    --- PASS: TestCreate/Case_1:_project_name_is_given (0.00s)
    --- PASS: TestCreate/Case_2:_no_project_name_given (0.00s)
    --- FAIL: TestCreate/Case_3:_Invalid_project_name_is_given (0.00s)
        project_test.go:94: project Create() unexpected error <nil>, wantErr true
FAIL

Debugger finished with exit code 0
@amitkrout
Copy link
Contributor

#2257 (comment)

@kadel
Copy link
Member

kadel commented Oct 23, 2019

This is actually not a bug but a feature :-) of a fakeclient. In the k8s cluster the validation happens on the server. Fake client, as the name suggests is just a client and there is no sever, so there can't be any validation.

@amitkrout
Copy link
Contributor

This is actually not a bug but a feature :-) of a fakeclient. In the k8s cluster the validation happens on the server. Fake client, as the name suggests is just a client and there is no sever, so there can't be any validation.

Right, But is there any way to validate such cases using fakeclient ? If no then then the scenario of incorrect project name will be taken care in integration test.

@girishramnani
Copy link
Contributor

This is one of those cases where odo shouldn't be responsible for testing this ( on a unit level atleast), as the tests for validation would have been written by k8s cluster ( as the validation happens on that end )

@girishramnani
Copy link
Contributor

An integration test might still make sense if you want to validate this behavior with some other behavior across modules or function.

@kadel
Copy link
Member

kadel commented Oct 23, 2019

This is one of those cases where odo shouldn't be responsible for testing this ( on a unit level atleast), as the tests for validation would have been written by k8s cluster ( as the validation happens on that end )

+1
And I would add to that that this case, is actually something that should be in integration test rather unit test

@amitkrout
Copy link
Contributor

Thanks for the clarification. Will take care it in integration test. I guess there is a scenario in integration test, otherwise will add one.

/close

@openshift-ci-robot
Copy link
Collaborator

@amitkrout: Closing this issue.

In response to this:

Thanks for the clarification. Will take care it in integration test. I guess there is a scenario in integration test, otherwise will add one.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

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

5 participants