Add unit tests #54
Add unit tests #54
Conversation
carlcsaposs-canonical
requested review from
paulomach,
taurus-forever and
shayancanonical
|
You can review the difference from k8s PR here: https://github.com/canonical/mysql-router-operator/pull/54/files/f96b683cac1f9566f8b8f3af3d7517681f5026aa..HEAD |
Codecov Report
@@ Coverage Diff @@
## main #54 +/- ##
===========================================
+ Coverage 50.23% 73.45% +23.21%
===========================================
Files 7 14 +7
Lines 428 953 +525
Branches 57 110 +53
===========================================
+ Hits 215 700 +485
- Misses 200 223 +23
- Partials 13 30 +17
|
tests/unit/scenario_/database_relations/test_database_relations_breaking.py
Show resolved
Hide resolved
| assert state.relations[-1].local_app_data == {} | ||
| complete_provides_s.pop() | ||
| for index, provides in enumerate(complete_provides_s, 1): | ||
| assert state.relations[index].local_app_data == { |
There was a problem hiding this comment.
take a look at State.get_relations, maybe it can be handy for filtering out what relations you want to look at.
I spent some time thinking about how it'd be handy to expose the relations, but I wasn't sure.
would a get_relation_by_id be better?
There was a problem hiding this comment.
would a
get_relation_by_idbe better?
Yes I think so—so that we can use the input scenario.Relation to access the output scenario.Relation
If you look at this example:
complete_provides_s and incomplete_provides_s relations have the same endpoint, but we need to make different assertions on them
There was a problem hiding this comment.
yeah precisely. I had this issue: canonical/ops-scenario#20 to track ideas and proposals around this use case
There was a problem hiding this comment.
something like obj_out = state_out.get_me_corresponding_object(obj_in)
CI should not fail if code coverage drops Except for TLS and the legacy shared-db relation (which I skipped in #54), adding additional unit testing would have, imo, little to negative value since it would require extensive mocking and would essentially only be testing if the internal APIs of the charm have changed (which they should, as the charm evolves and is refactored) Therefore, I don't think it's useful to have a failed CI run if code coverage drops
CI should not fail if code coverage drops Except for TLS and the legacy shared-db relation (which I skipped in #54), adding additional unit testing would have, imo, little to negative value since it would require extensive mocking and would essentially only be testing if the internal APIs of the charm have changed (which they should, as the charm evolves and is refactored) Therefore, I don't think it's useful to have a failed CI run if code coverage drops
Ported from canonical/mysql-router-k8s-operator#110