unit test: verify the func generate_kbs_auth_public_key#20
Conversation
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>
| // 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); | ||
| }); |
There was a problem hiding this comment.
can we create a module where we define the kubernetes mocked client? This logic should be reused multiple times by the tests
| "apiVersion": "v1", | ||
| "kind": "Secret", | ||
| "metadata": { | ||
| "name": "test-secret-name", | ||
| "namespace": "test-namespace" |
There was a problem hiding this comment.
can we also reuse the kubernetes structures defined in the kube-rs crate. We shouldn really not hardcode any of the kubernetes objects
|
|
||
| // 5. Cleanup filesystem side effects | ||
| let _ = fs::remove_file("privateKey"); | ||
| let _ = fs::remove_file("publicKey"); |
There was a problem hiding this comment.
does rust have some teardown logic? I will be much more clean if this was separated from the main logic of the test
There was a problem hiding this comment.
Same thing if the test requires some setup to make it working. This could be for example the initialization of the mocking frameworking
There was a problem hiding this comment.
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
| 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()); |
There was a problem hiding this comment.
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
|
@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 |
|
This PR has been superseded by #53 |
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