Skip to content

Testing

sputlab edited this page Nov 13, 2026 · 1 revision

Testing

Run the unit tests

./gradlew testDebugUnitTest

All tests run on the JVM, with no phone needed.

How tests work

JVM tests use the in-memory mesh in TestSupport.kt with a virtual clock and per-node random seeds, so they are deterministic. The crypto and protocol code is free of Android APIs for exactly this reason.

Test classes

Area Tests
Crypto CryptoTest, HkdfTest, SessionManagerTest, ContactCodeTest
Wire format and routing PacketTest, HelloPayloadTest, HelloSchedulingTest, NodeAdvertisementTest, RoutingTest
Mesh simulation MeshNetworkTest (encrypted multi-node, relay), GroupNetworkTest
Groups and directory GroupCodecTest, DirectoryTest
Bulk data VoiceTransferTest, PhotoTransferTest, TransferAssemblerTest
Fast link FastLinkTest
Other MapFilesTest, LinkBenchmarkTest

Rules for new tests

  • Security tests: every security property needs a test that fails when the check is removed. Verify it by breaking the check on purpose and confirming the test fails; a test that also passes without the check is worthless.
  • Relay: extend MeshNetworkTest whenever relay behaviour changes.
  • Sessions: any change to session adoption or retirement needs a test with both ends starting a handshake at the same moment and a long virtual-time run. A real bug (each end dropping the session the other still used) was found that way.
  • Groups: every group rule (membership, admin, joined state) needs a test that fails when the check is removed.
  • Blobs: a new kind of blob goes through BlobPolicy and must be refused on slow links.

Testing on real phones

See Getting Started for the two-phone and three-phone (relay) procedures. The website has a test report form for reporting results on a device, and a list of tested devices (Honor View 10, Xiaomi Mi Note 10, Sony Xperia XQ-AS52, Samsung Galaxy A52).

Clone this wiki locally