Replies: 1 comment 3 replies
-
|
lightyear_tests was mainly intended to be used only for internal tests, but i'm open for more types to be public + publishing it if it's helpful. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Context
I'm building a multiplayer game using Lightyear 0.24.2 and want to write integration tests for client-server interactions (entity replication, input handling) without running full graphical clients.
I discovered
lightyear_tests::stepper::ClientServerStepperwhich looks perfect, but I'm hitting visibility issues.Current Problem
My test code:
Compilation errors:
These are marked
pub(crate)inlightyear_tests/src/stepper.rs.Why I Need This
Without Lightyear's testing utilities, I'm stuck with:
./run_local.shis slow, not CI-friendly, hard to reproduce scenariosThe
ClientServerStepperpattern is exactly what I need: fast headless tests, full protocol stack, deterministic simulation, easy assertions.Questions
Is
lightyear_testsintended for external projects? The crate exists but all APIs arepub(crate). Should I use a different approach?Would you consider publishing
lightyear_testsas a public crate? Similar tobevy_ecstest utilities - this would help the ecosystem significantly.What's the recommended testing strategy meanwhile?
pathdependency with visibility changes?Alternative I'm Using
I wrote simpler unit tests:
This validates spawn logic but not actual replication, prediction, input buffering, or network behavior.
Reference
pub):server/tests/stepper_connection_test.rsClientServerStepper::default()(public) but notdefault_no_init()(private)Thanks for building Lightyear - just trying to figure out best testing practices! 🙏
Beta Was this translation helpful? Give feedback.
All reactions