doc: add base doc that clarifies how users can test their projects #3823
Conversation
camilamacedo86
requested review from
bharathi-tenneti,
dmesser,
jmccormick2001,
jmrodri and
varshaprasad96
and removed request for
shawn-hurley and
hasbro17
camilamacedo86
force-pushed
the
doc-tests
branch
from
f59797e
to
29f841c
Compare
camilamacedo86
force-pushed
the
doc-tests
branch
from
29f841c
to
fc7fdb8
Compare
|
Couple more nits, then this looks good to go. |
camilamacedo86
force-pushed
the
doc-tests
branch
from
fc7fdb8
to
8febbf3
Compare
|
Hi @jberkhahn, Really thank you for your review. All nits addressed. |
| go test controllers/ -v -ginkgo.v | ||
| ``` | ||
|
|
||
| The projects generated by using the SDK tool have a Makefile which contains the target tests which executes when you run make test. Note that this target will also execute when you run `make docker-build IMG=<some-registry>/<project-name>:<tag>` the test also will be executed. |
There was a problem hiding this comment.
the last bit of the sentence "the test also will be executed" is uneeded and can be deleted.
|
one more thing and this although your tests seem to be blowing up |
|
/lgtm |
camilamacedo86
force-pushed
the
doc-tests
branch
from
cc71241
to
ea166f0
Compare
camilamacedo86
force-pushed
the
doc-tests
branch
from
ea166f0
to
b41ae2c
Compare
|
/lgtm |
jmrodri
changed the title
| @@ -230,11 +230,11 @@ test: generate fmt vet manifests | |||
|
|
|||
| ## Migrate your tests | |||
|
|
|||
| For the new layout, you will see that `controllers/suite_test.go` is created. This file contains boilerplate for executing integration tests using [envtest][envtest] with [ginkgo](https://onsi.github.io/ginkgo/) and [gomega](https://onsi.github.io/gomega/). | |||
| For the new layout, you will see that `controllers/suite_test.go` is created when a controller is scaffolded by the tool. This file contains boilerplate for executing integration tests using [envtest][envtest] with [ginkgo](https://onsi.github.io/ginkgo/) and [gomega](https://onsi.github.io/gomega/). | |||
There was a problem hiding this comment.
I guess we should just be consistent with how we handle links. Add ginkgo and gomega to the bottom with the other links.
|
|
||
| Operator SDK 1.0.0+ removes support for the legacy test framework and no longer supports the `operator-sdk test` subcommand. All affected tests should be migrated to use `envtest`. | ||
|
|
||
| The Operator SDK project recommends controller-runtime's [envtest][envtest] because it has a more active contributor community, it has become more mature than Operator SDK's test framework, and it does not require an actual cluster to run tests, which can be a huge benefit in CI scenarios. | ||
| The Operator SDK project recommends using controller-runtime's [envtest][envtest] to write tests for your Operators projects because it has a more active contributor community, it has become more mature than Operator SDK's test framework, and it does not require an actual cluster to run tests, which can be a huge benefit in CI scenarios. |
There was a problem hiding this comment.
Split the sentence up.
The Operator SDK project recommends using controller-runtime's [envtest][envtest] to write tests for your Operators projects. Envtest has a more active contributor community, it is more mature than Operator SDK's test framework, and it does not require an actual cluster to run tests which can be a huge benefit in CI scenarios.
|
|
||
| ## Overview | ||
|
|
||
| The Operator SDK project recommends using controller-runtime's [envtest][envtest] to write tests for your Operators projects because it has a more active contributor community, it has become more mature than Operator SDK's test framework, and it does not require an actual cluster to run tests, which can be a huge benefit in CI scenarios. |
There was a problem hiding this comment.
Split the sentence up.
The Operator SDK project recommends using controller-runtime's [envtest][envtest] to write tests for your Operators projects. Envtest has a more active contributor community, it is more mature than Operator SDK's test framework, and it does not require an actual cluster to run tests which can be a huge benefit in CI scenarios.
|
|
||
| ## Using EnvTest | ||
|
|
||
| You will see that `controllers/suite_test.go` is created when a controller is scaffolded by the tool. This file contains boilerplate for executing integration tests using [envtest][envtest] with [ginkgo](https://onsi.github.io/ginkgo/) and [gomega](https://onsi.github.io/gomega/). |
There was a problem hiding this comment.
We should just be consistent with how we handle links. Add ginkgo and gomega to the bottom with the other links.
| go test controllers/ -v -ginkgo.v | ||
| ``` | ||
|
|
||
| The projects generated by using the SDK tool have a Makefile which contains the target tests which executes when you run make test. Note that this target will also execute when you run `make docker-build IMG=<some-registry>/<project-name>:<tag>`. |
|
|
||
| ## Other Options | ||
|
|
||
| Also you can write tests for your operator in a declarative using the [kuttl](https://kuttl.dev/). Via kuttl, you can define YAML manifests that specify the expected before and after statues of a cluster when your operator is used. For more info see [Writing Kuttl Scorecard Tests][writing-kuttl-scorecard-tests]. |
There was a problem hiding this comment.
Also, you can write tests for your operator in a declarative manner using [kuttl][kuttl]. With kuttl, you define YAML manifests that contain the expected before and after states of the cluster. For more info see [Writing Kuttl Scorecard Tests][writing-kuttl-scorecard-tests].
Put the kuttl link with the other links in the doc.
kuttl
|
|
||
| Also you can write tests for your operator in a declarative using the [kuttl](https://kuttl.dev/). Via kuttl, you can define YAML manifests that specify the expected before and after statues of a cluster when your operator is used. For more info see [Writing Kuttl Scorecard Tests][writing-kuttl-scorecard-tests]. | ||
|
|
||
| To implement application-specific tests, the test harness of the SDK, [scorecard][scorecard], provides the ability to ship custom code in container images as well, which can be referenced in the test suite. Because this test suite definition metadata travels with the Operator Bundle, it allows for functional testing of the Operator without the source code or the project layout being available. See [Writing Custom Scorecard Tests][writing-custom-scorecard-tests]. |
There was a problem hiding this comment.
change: the test harness of the SDK -> the SDK's test harness
| [envtest-setup]: /docs/building-operators/golang/references/envtest-setup | ||
| [writing-kuttl-scorecard-tests]: /docs/advanced-topics/scorecard/kuttl-tests | ||
| [writing-custom-scorecard-tests]: /docs/advanced-topics/scorecard/custom-tests | ||
| [scorecard]: /docs/advanced-topics/scorecard/scorecard |
|
Really thank you for your time @jmrodri and help with this review. |
camilamacedo86
force-pushed
the
doc-tests
branch
from
edb67b1
to
5ed8d89
Compare
…perator-framework#3823) **Description of the change:** doc: add base doc to clarifies how users can test their projects **Motivation for the change:** Many users have raised these questions. The goal of this doc is to provide the basic information and the links/references for they are able to move forward. It can be improved by the community and/or in the post 1.0 doc plans. Closes: operator-framework#3511
Description of the change:
doc: add base doc to clarifies how users can test their projects
Motivation for the change:
Many users have raised these questions. The goal of this doc is to provide the basic information and the links/references for they are able to move forward. It can be improved by the community and/or in the post 1.0 doc plans.
Closes: #3511
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs