Fuzz testing: research existing KMP/Kotlin ecosystem tooling

Offen
#983 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Dokumentation
Klarheit
Klar beschrieben
Aktivitätsstatus
Ruhig
Tech-Stack
java, kotlin, machine-learning

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Vorherrschende Sprache
Kotlin
Sterne
52
Forks
15
Ø Merge
23 Std. 32 Min.
Gemergte PRs (30 T.)
81

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SKaiNET-developers/SKaiNET

Alle Issues in SKaiNET-developers/SKaiNET

Ähnliche Issues

Weitere Issues zu Kotlin

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.