Testing tooling
Some ad hoc test-writing during development used JetBrains' AI IDE assistant, Junie, inside Android Studio.
How it was used: rather than hand-writing test scaffolding, specific functions were selected and Junie was prompted directly against them — describing the behavior to check and asking it to draft a test case in place. This was exploratory, prompt-driven verification during iteration, not a standing automated suite generated up front.
The kind of logic this targeted: areas of the shared commonMain
module with non-obvious edge-case behavior were natural candidates —
for example the port-fallback probe in
TextTransport.start()
(binding falls back through a range of ports before giving up), PIN
validation in the pairing flow, and the free-vs-Pro gating checks that
decide whether a peer can pair or send a file. These are the spots
where a wrong assumption is easy to miss just by reading the code, so
prompting an assistant to reason through cases like "port already in
use," "PIN expired," or "already at the free device limit" was a
useful quick check against the implementation's actual behavior.
Honest limitations: this was a development aid, not a CI-enforced
safety net. The repo has no test//androidTest//iosTest source
set, no coverage report, and nothing here was wired into GitHub Actions.
If Beam moves toward a real test suite, formalizing these prompted
checks into a proper Kotlin commonTest module (using kotlin.test,
which already ships with the KMP toolchain) is the natural next step.
Log in or sign up for Devpost to join the conversation.