-
Notifications
You must be signed in to change notification settings - Fork 9
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
test: integration tests for akri and opcua checks #225
Conversation
you are right, also |
want to double check if you tried to test these both with and without deployment some Akri and OPC UA resources? if not I can help to check as well |
@pytest.mark.parametrize("detail_level", ResourceOutputDetailLevel.list()) | ||
@pytest.mark.parametrize("resource_kind", AkriResourceKinds.list() + [None]) | ||
# TODO: figure out if name match should be a general test vs each service (minimize test runs) | ||
@pytest.mark.parametrize("resource_match", [None, "*otel*", "akri-opcua*", generate_names()]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leaning towards removing resource match testing here (and in opcua) and adding a todo for general resource match testing.
) -> Dict[str, Any]: | ||
def pass_conditions(item: Dict[str, Any]) -> bool: | ||
name = item["metadata"]["name"] | ||
if resource_match and not fnmatch(name, resource_match): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can change into a single return
return any([ not resource_match and not prefixes, resource_match and fnmatch(name, resource_match), prefixes and any(name.startswith(prefix) for prefix in prefixes) ])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the different if
statements are checking for different scenarios, it's totally plausible to leave them as two separate statements - in case we need to change future logic in one but not another.
namespace_status = "success" | ||
assert not runtime_resource[namespace]["conditions"] | ||
evals = runtime_resource[namespace]["evaluations"] | ||
kubectl_pods = get_kubectl_workload_items( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will need to make this into a helper function for mq pod checks
return {cond["name"]: cond for cond in result["postDeployment"]}, service_present | ||
|
||
|
||
def sort_by_namespace( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should add in doc strings describing what the functions do...
if isinstance(prefixes, str): | ||
prefixes = [prefixes] | ||
namespace_param = f"-n {namespace}" if namespace else "-A" | ||
kubectl_items = run(f"kubectl get {service_type}s {namespace_param} -o json") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A word of caution for use with future checks - I believe certain CRDs may have a plural that isn't s
def test_check(init_setup, detail_level, services_map, post, pre): | ||
ops_service, resources = services_map | ||
resources = " ".join(resources) | ||
command = f"az iot ops check --as-object --detail-level {detail_level} --ops-service {ops_service} "\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the --detail-level
param tested elsewhere? Or will each services' checks need to iterate through available detail levels?
Akri check integration tests
--as-object
needs loveFuture tasks:
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
Thank you for contributing to Azure IoT Operations tooling!
This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines
Intent for Production
dev
ormain
are of production grade. Corollary to this, any merged contributions to these branches may be deployed in a public release at any given time. By checking this box, you agree and commit to the expected production quality of code.Basic expectations
pytest <project root> -vv
. Please provide evidence in the form of a screenshot showing a succesful run of tests locally OR a link to a test pipeline that has been run against the change-set..pylintrc
and.flake8
rules? Look at the CI scripts for example usage.Azure IoT Operations CLI maintainers reserve the right to enforce any of the outlined expectations.
A PR is considered ready for review when all basic expectations have been met (or do not apply).