For some features, it's easier to just have a unittest demonstrate
the expected behavior. This sets up that framework, and modifies
the existing code to make it more explicit as to what is going on
when debugging.
Depends on D7659
Details
Details
- Reviewers
varun bartek - Commits
- rCOMM2bead14e6f9c: [Tunnelbroker] Add integration tests
(cd services/tunnelbroker && RUST_LOG=debug cargo run &) cd services/commtest && cargo test --test tunnelbroker_integration_test
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- jonringer/tunnelbroker-connections (branched from master)
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/commtest/tests/tunnelbroker_integration_test.rs | ||
|---|---|---|
| 4–5 | I know this is a "hello world" test, but just two considerations for future design:
| |
| services/tunnelbroker/src/websockets/mod.rs | ||
| 70 | I'd consider it trace! because it feels redundant as there's already a debug log in line 45 | |
| services/commtest/tests/tunnelbroker_integration_test.rs | ||
|---|---|---|
| 4–5 |
It is meant to be a test. It's easier for me to iterate with rust than JS. So I've been implementing it first in rust to just to ensure that the rust is working before trying to debug stuff in JS.
The test is meant to a be a happy case, if it panics or returns an Err it will still fail the test. I don't feel super strongly about this, and might make the transition in the future to use anyhow. Still not sure if anyhow or retaining the original error is more beneficial | |
| services/tunnelbroker/src/websockets/mod.rs | ||
| 70 | line 45 doesn't get executed until a message is received, where as this gets emitted right before it begins polling for an event. | |