Add Unit Test Coverage for Core Components

[rsthornton]

Description: BERT currently has no unit tests. This creates risk for regressions as the codebase evolves and makes it difficult for new contributors to verify their changes don't break existing functionality. This issue focuses on adding foundational test coverage for core system modeling components with a clear, incremental plan.

User Value:

• Prevents bugs and regressions in system modeling logic
• Enables confident refactoring and feature additions
• Provides documentation of expected component behavior
• Establishes testing patterns for future contributors

Technical Implementation Tasks:

1. Core Component Testing:

   • Add #[cfg(test)] modules to system_elements.rs
   • Test component creation, validation, and property setting
   • Test serialization/deserialization round-trips
   • Verify component relationship handling

2. Data Model Testing:

   • Test system hierarchy creation and validation
   • Test interface and flow creation logic
   • Verify boundary condition handling
   • Test model complexity calculations

3. Test Infrastructure:

   • Set up test utilities for creating sample models
   • Add helper functions for common test scenarios
   • Establish naming conventions and organization patterns

Scope:

• Start with pure-Rust unit tests that do not require spinning up a Bevy App. Focus on components and data structures in:
  • bert/bert/src/bevy_app/components/system_elements.rs
  • bert/bert/src/bevy_app/data_model/* (e.g., save.rs, load.rs, complexity_calculator.rs)
• Add a small set of integration tests under bert/bert/tests/ for save/load round-trips using JSON fixtures.

File Pointers:

• Components under test: bert/bert/src/bevy_app/components/system_elements.rs
• Data model serialization: bert/bert/src/bevy_app/data_model/save.rs, load.rs, mod.rs
• Complexity: bert/bert/src/bevy_app/data_model/complexity_calculator.rs
• Create fixtures: bert/bert/fixtures/ (add 2–3 tiny JSON models)

Concrete Test Plan:

1. Unit tests in system_elements.rs (#[cfg(test)] module):

   • InteractionUsability::{is_useful,is_import,is_export} truth table
   • SubstanceType::{flow_color,interface_color,to_rgb_string} basic invariants (e.g., colors differ between types)
   • InterfaceSubsystem::new initializes defaults and preserves interface_entity
   • Parameter serde: id is skipped on serialize and defaults on deserialize; round-trip preserves fields
   • SystemElement Display/enum variants consistency checks

2. Unit tests for data model (place nearest to code or in tests/ if cleaner):

   • serialize_world then load_world round-trip preserves essential fields for a minimal model
   • WorldModel boundary cases: empty model, single system, simple flow
   • calculate_simonian_complexity returns non-negative values; increases with added elements

3. Integration tests in bert/bert/tests/:

   • Load fixture JSON(s) from bert/bert/fixtures/ and verify round-trip stability and basic invariants

Test Structure & Conventions:

• Prefer colocated #[cfg(test)] modules for component units; use tests/ for integration
• Name tests clearly, e.g., interaction_usability_truth_table, parameter_serde_round_trip
• Use assert!, assert_eq!, and table-driven loops where helpful
• Keep tests deterministic; avoid relying on system time

Getting Started:

• Run: cargo test -p bert inside bert/
• Add #[cfg(test)] modules to system_elements.rs for the component tests
• Create bert/bert/tests/ and add an integration test file (e.g., save_load_roundtrip.rs)
• Create bert/bert/fixtures/ and add 2–3 tiny JSON models if not present

Acceptance Criteria:
Must Have:

• At least 10 unit tests covering the items listed in the Concrete Test Plan (unit section)
• At least 1 integration test covering save/load round-trip using a fixture
• All tests pass with cargo test -p bert
• Brief inline doc comments per test explaining what is being verified

Nice to Have:

• Additional integration tests for multiple fixtures
• Property-based tests (e.g., proptest) for Parameter or WorldModel
• Test coverage reporting (e.g., cargo tarpaulin) documented but not required
• Benchmark tests for performance-critical operations (separate PR acceptable)

[FrankiePower]

are these issues still available to be handled?? and is it a part of the merit tracks for rewards

[rsthornton]

Hi @FrankiePower, this repo and the issues are a bit outdated, check back in a few weeks for an update. There is a merit project associated with this repo, but I'm not sure what you mean by the "merit tracks for rewards"?

https://terminal.merit.systems/halcyonic-systems/bert