Splitting test into unit and integration tests to match with Rust testing standards

[Synicix]

Depends on #111

After taking a look at using cargo features to allow testing. I believe this strays too far from the standard way Rust expects us to test things. In short I am splitting them based on the purpose of the test.

• Test folder (Integration test, testing usage of orcapod from the user side)
• Integrated test mods in the actual code files (For unit and internal test): Note the compiler does not compile the unit test unless you run cargo test as documented here: https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest

Resolves PIPE-118

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[Copilot]

Pull Request Overview

This PR refactors the test organization to follow Rust testing standards by splitting tests into unit tests (within modules using #[cfg(test)]) and integration tests (in the tests/ directory). The changes move tests from the top-level tests/ directory that were testing internal implementation details into unit test modules within the source code files, while keeping true integration tests that verify public API usage in the tests/ directory.

• Moved internal API tests (crypto, operator) from integration tests to unit tests within source modules
• Updated test imports and API usage to reflect restructured modules and updated field names
• Added new pipeline functionality with proper test coverage and data fixtures

Reviewed Changes

Copilot reviewed 43 out of 44 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
tests/store.rs	Updated imports and refactored pod annotation test with cleaner Pod construction
tests/pipeline_runner.rs	New integration test for pipeline runner functionality
tests/pipeline.rs	Updated API calls to use new field names (NodeURI, pod instead of ref)
tests/orchestrator.rs	Fixed iteration and filtering logic for container operations
tests/operator.rs	Removed - moved to unit tests in src/core/operator.rs
tests/model.rs	Updated hash values and test assertions
tests/fixture/mod.rs	Added extensive pipeline test fixtures and helper functions
tests/crypto.rs	Removed - moved to unit tests in src/core/crypto.rs
tests/agent.rs	Updated metadata extraction to use manual parsing instead of removed utility
src/core/operator.rs	Added unit tests moved from integration tests
src/core/crypto.rs	Added unit tests moved from integration tests

Comments suppressed due to low confidence (1)

src/core/pipeline_runner.rs:1

• Unnecessary double vector wrapping. Should be chain(std::iter::once(vec![packet.clone()])) for better performance and clarity.

use crate::{

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The metadata parsing logic is incorrect. This creates key-value pairs from consecutive elements, but the key expression format requires proper parsing of the structured path segments.

Suggested change

	let metadata: HashMap<String, String> = sample
	.key_expr()
	.as_str()
	.split('/')
	.map(ToOwned::to_owned)
	.tuples()
	.collect();
	let topic_kind = metadata["event"].as_str();
	// Properly parse the key expression to extract the event kind
	let key_segments: Vec<&str> = sample
	.key_expr()
	.as_str()
	.split('/')
	.collect();
	// Find the segment after "pod_job" (which should be the event kind)
	let topic_kind = key_segments
	.iter()
	.position(|&seg| seg == "pod_job")
	.and_then(|idx| key_segments.get(idx + 1))
	.map(|s| *s)
	.unwrap_or("");

[codecov]

Codecov Report

❌ Patch coverage is 85.21635% with 123 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/core/pipeline_runner.rs	81.37%	92 Missing ⚠️
src/core/error.rs	0.00%	8 Missing ⚠️
src/core/operator.rs	96.59%	6 Missing ⚠️
src/uniffi/model/packet.rs	50.00%	6 Missing ⚠️
src/uniffi/model/pipeline.rs	64.28%	5 Missing ⚠️
src/core/crypto.rs	89.28%	3 Missing ⚠️
src/uniffi/orchestrator/docker.rs	81.25%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[eywalker]

Have reviewed through in-person discussion. This, however, warrants a more thorough future visit upon completely cleaning up the series of PRs.