docs: separate test_workload_version_is_set in k8s tutorial chapter 3#2638
docs: separate test_workload_version_is_set in k8s tutorial chapter 3#2638tromai wants to merge 3 commits into
Conversation
| logger = logging.getLogger(__name__) | ||
|
|
||
| METADATA = yaml.safe_load(pathlib.Path("./charmcraft.yaml").read_text()) | ||
| METADATA = yaml.safe_load(pathlib.Path("charmcraft.yaml").read_text()) |
There was a problem hiding this comment.
I made this change to following what we have in Chapter 1. Please let me know if the ./ is intentional here.
There was a problem hiding this comment.
Good catch, thanks. The version without ./ matches the Charmcraft profile (see https://github.com/canonical/charmcraft/blob/main/charmcraft/templates/init-kubernetes/tests/integration/test_charm.py.j2)
There was a problem hiding this comment.
I'm not sure if it's in the scope.
The content we suggest here is different from Chapter 2 in 2 places:
- From
juju.wait(jubilant.all_active)tojuju.wait(jubilant.all_blocked) - The doc string
Assert on the unit status before any relations/configurations take place.
We can simplify by describing a diff, instead of a whole file replacement:
- """Deploy the charm under test."""
+ """Deploy the charm under test.
+
+ Assert on the unit status before any relations/configurations take place.
+ """
...
- juju.wait(jubilant.all_active)
+ juju.wait(jubilant.all_blocked)There was a problem hiding this comment.
I agree with you. I don't see why we need to rewrite the whole file. I think it will be clearer for the reader if we tell them exactly what to change.
With that in mind, I suggest making the format of test_deploy match closer with chapter 2. Keep the same docstring and remove the comment before juju.deploy (the tutorial already explains things sufficiently).
This means the only change needed is all_active --> all_blocked. The tutorial can effectively just say that 😁
I've added suggestions on the testing code.
| def test_workload_version_is_set(juju: jubilant.Juju): | ||
| # Verify that the workload version has been set. | ||
| version = juju.status().apps[APP_NAME].version | ||
| assert version == "1.0.4" # Hardcoded for simplicity. |
There was a problem hiding this comment.
Interesting, I was expecting we'd put this test after test_database_integration (which unblocks the charm). But I think you're right; it doesn't matter that the charm is blocked, as that's coming from the collect-status handler.
There was a problem hiding this comment.
Oh, I only moved this function because it follows the tutorial where we said "add the test_database_integration" test.
I thought it's more natural for test_database_integration to be after test_workload_version_is_set. It works well as you confirmed, but I'm happy to revert it back this change doesn't make sense 🤔
There was a problem hiding this comment.
I agree with you. I don't see why we need to rewrite the whole file. I think it will be clearer for the reader if we tell them exactly what to change.
With that in mind, I suggest making the format of test_deploy match closer with chapter 2. Keep the same docstring and remove the comment before juju.deploy (the tutorial already explains things sufficiently).
This means the only change needed is all_active --> all_blocked. The tutorial can effectively just say that 😁
I've added suggestions on the testing code.
…leaning up; mention why we need charm fixture in all integration tests; simplify integration test section of chapter 3
| ## Write an integration test | ||
|
|
||
| Now that our charm integrates with the database, if there's not a database relation, the app will be in `blocked` status instead of `active`. Let's tweak our existing integration test `test_deploy` accordingly, to expect blocked status in `juju.wait`. Replace the contents of `tests/integration/test_charm.py` with: | ||
| Now that our charm integrates with the database, if there's not a database relation, the app will be in `blocked` status instead of `active`. In your `tests/integration/test_charm.py` file, update `test_deploy` to expect blocked status: |
There was a problem hiding this comment.
This is my attempt to simplify the description. I am happy to keep the "Let's tweak ..." if that is preferred
Let's tweak our existing integration test `test_deploy` accordingly, to expect blocked status in `juju.wait`.
Update `test_deploy` in your `tests/integration/test_charm.py` with:
2 participants
This PR brought
test_workload_version_is_setback to life in chapter 3, and propagate that change to chapter 4 and 5. It also updated the exampleexamples/k8s-*/tests/integration/test_charm.pyfiles.Doc preview
It was raised by David: