Skip to content

unit test: verify the func generate_kbs_auth_public_key#20

Closed
6-dehan wants to merge 1 commit into
mainfrom
unittest_verify_func_generate_kbs_auth_public_key
Closed

unit test: verify the func generate_kbs_auth_public_key#20
6-dehan wants to merge 1 commit into
mainfrom
unittest_verify_func_generate_kbs_auth_public_key

Conversation

@6-dehan
Copy link
Copy Markdown
Contributor

@6-dehan 6-dehan commented Sep 11, 2025

Testing key generation and file writing logic (e.g., whether the privateKey and publicKey file contents and base64 encoding are correct) does not require
a mock K8s client.

Signed-off-by: Dehan Meng demeng@redhat.com

Testing key generation and file writing logic (e.g.,
whether the privateKey and publicKey file contents and
base64 encoding are correct) does not require
a mock K8s client.

Signed-off-by: Dehan Meng <demeng@redhat.com>
@6-dehan 6-dehan marked this pull request as draft September 11, 2025 08:44
Comment thread operator/src/trustee.rs
Comment on lines +381 to +425
// 1. Setup the mock K8s API server
let (mock_service, mut handle) = mock::pair::<http::Request<Body>, http::Response<Body>>();
let service = ServiceBuilder::new().service(mock_service);
let client = Client::new(service, "default");

// 2. Define the expected API call and the response in a separate task
let handle = tokio::spawn(async move {
// Expect a single request to create a Secret
let (request, send) = handle
.next_request()
.await
.expect("service received a request");

// Assertions on the request
assert_eq!(request.method(), "POST");
assert_eq!(
request.uri().path(),
"/api/v1/namespaces/test-namespace/secrets"
);

// Extract and deserialize the body to check its content
let body_bytes = request.into_body().collect().await.unwrap().to_bytes();
let secret: Secret = serde_json::from_slice(&body_bytes).unwrap();
assert_eq!(secret.metadata.name.as_deref(), Some("test-secret-name"));

// Check that the publicKey field exists and is not empty
let data = secret.data.unwrap();
let public_key_b64 = data.get("publicKey").unwrap();
assert!(!public_key_b64.0.is_empty());

// Send back a successful response
let response_secret = json!({
"apiVersion": "v1",
"kind": "Secret",
"metadata": {
"name": "test-secret-name",
"namespace": "test-namespace"
}
});
let response = http::Response::builder()
.status(201)
.body(Body::from(response_secret.to_string().into_bytes()))
.unwrap();
send.send_response(response);
});
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we create a module where we define the kubernetes mocked client? This logic should be reused multiple times by the tests

Comment thread operator/src/trustee.rs
Comment on lines +413 to +417
"apiVersion": "v1",
"kind": "Secret",
"metadata": {
"name": "test-secret-name",
"namespace": "test-namespace"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we also reuse the kubernetes structures defined in the kube-rs crate. We shouldn really not hardcode any of the kubernetes objects

Comment thread operator/src/trustee.rs
Comment on lines +436 to +439

// 5. Cleanup filesystem side effects
let _ = fs::remove_file("privateKey");
let _ = fs::remove_file("publicKey");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does rust have some teardown logic? I will be much more clean if this was separated from the main logic of the test

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing if the test requires some setup to make it working. This could be for example the initialization of the mocking frameworking

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For rust, apprently there isn't a framework with builtin setup and teardonw, but at least for teardown you could create a drop function, see https://stackoverflow.com/questions/73008377/rust-create-test-setup

Comment thread operator/src/trustee.rs
Comment on lines +403 to +409
let secret: Secret = serde_json::from_slice(&body_bytes).unwrap();
assert_eq!(secret.metadata.name.as_deref(), Some("test-secret-name"));

// Check that the publicKey field exists and is not empty
let data = secret.data.unwrap();
let public_key_b64 = data.get("publicKey").unwrap();
assert!(!public_key_b64.0.is_empty());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, extract this part and include it in the setup of the test. See the comment: https://github.com/confidential-clusters/cocl-operator/pull/20/files#r2340577927

@alicefr
Copy link
Copy Markdown
Contributor

alicefr commented Sep 11, 2025

@6-dehan my general comment is try to generalize and encapsulate the generic logic as much as possible. There is a lot of logic here that will be reused by multiple tests, we want to keep the code for each tests as minimal as possible, and reuse the common logic

@alicefr
Copy link
Copy Markdown
Contributor

alicefr commented Oct 13, 2025

This PR has been superseded by #53

@alicefr alicefr closed this Oct 13, 2025
@Jakob-Naucke Jakob-Naucke deleted the unittest_verify_func_generate_kbs_auth_public_key branch October 13, 2025 07:18
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

Successfully merging this pull request may close these issues.

2 participants