Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Fuzz testing: research existing KMP/Kotlin ecosystem tooling

Open
#983 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Tech stack
java, kotlin, machine-learning

Research direction

This is research for parent #981, not an implementation ticket. Start from the listed candidates (Jazzer, Jazzer.js, kotest property testing, JUnit/kotlin.test generators) and check which run on KMP source sets versus jvmTest only. Note how each reports coverage (JaCoCo-style, Gradle/CI wiring) and how other Kotlin/JVM OSS projects time-box fuzz jobs, persist corpora, and report crashes. Done is a short comparison comment or doc page so #981 can pick tools; do not implement fuzzing here. Companion #982 can run in parallel.

Written by the indexing model from the issue text.

Description

enhancement research sub-issue

Sub-issue of #981 ("Enhance testing by adding fuzzing") — the R: RESEARCH phase for that
proposal. Survey what already exists in the Kotlin/KMP ecosystem before designing anything custom.

Goal

Answer "what can we reuse" before #981 gets to a design/implementation plan.

Tasks

  • Fuzzing engines/harnesses for Kotlin/JVM: Jazzer
    (JVM libFuzzer via coverage-guided bytecode instrumentation, the most mature option),
    Jazzer.js if a JS/Wasm-side target
    ever makes sense, kotlinx property-based testing options
    (kotest property testing),
    and plain JUnit/kotlin.test + custom generators as a baseline comparison.
  • KMP-specific constraints: which of the above actually work across KMP source sets vs.
    JVM-only — most fuzzing engines are JVM-bytecode-based (Jazzer) or Node-based (Jazzer.js),
    so figure out realistic target-set scope (likely jvmTest only, at least initially) rather
    than assuming multiplatform fuzzing is feasible.
  • Coverage measurement: how each candidate reports/measures coverage (Jazzer integrates
    with JaCoCo-style coverage; check what's practical to wire into this repo's existing
    Gradle/CI setup), and whether coverage-guided fuzzing (vs. blind random generation) is
    achievable here.
  • CI integration patterns: how other Kotlin/JVM OSS projects run fuzzing in CI — as a
    time-boxed job (e.g. N minutes/seeds per run, not exhaustive), corpus persistence between
    runs (cached seed corpus so regressions aren't re-discovered from scratch), and how crashes
    get reported/triaged (e.g. auto-filed issues vs. failing the build).
  • Reporting/eval: what output format(s) these tools produce (crash reproducers, minimized
    inputs, coverage deltas) and whether any of it is consumable by this repo's existing docs/
    Antora pipeline or needs a bespoke summary step.
  • OSS-Fuzz feasibility: whether SKaiNET could realistically be onboarded to
    OSS-Fuzz (free continuous fuzzing for open-source
    projects) given it already has Jazzer-based JVM project examples, as a longer-term option
    beyond local/CI-only fuzzing.

Output

A short comparison write-up (as a comment on this issue, or a doc page) — not a recommendation
that's already implemented, just enough for #981 to make an informed tool choice.

Related

  • Parent: #981
  • Companion sub-issue (repo-state analysis, can run in parallel): #982
Dominant language
Kotlin
Stars
52
Forks
15
Avg merge
1d 15h
Merged PRs (30d)
36

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SKaiNET-developers/SKaiNET

All issues in SKaiNET-developers/SKaiNET

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.