Fuzz testing: research existing KMP/Kotlin ecosystem tooling
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
- Bereich
- ai, developer-experience, machine-learning, testing, testing-qa, tooling
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
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,kotlinxproperty-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 (likelyjvmTestonly, 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
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus SKaiNET-developers/SKaiNET
-
coding size:s skill:kotlin-core sub-issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
SKaiNET-developers/SKaiNET#1421 ·
Maintainer antworten meist innerhalb von 1 Tag
-
coding size:s skill:kotlin-core sub-issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
SKaiNET-developers/SKaiNET#1419 ·
Maintainer antworten meist innerhalb von 1 Tag
-
coding good first issue size:s skill:kotlin-core sub-issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
SKaiNET-developers/SKaiNET#1418 ·
Maintainer antworten meist innerhalb von 1 Tag
-
[Lane 2 · kotlin-core] NotImplemented stubs — remove or implement TensorDefineDslImpl.create()Offencoding good first issue size:xs skill:kotlin-core sub-issue
Schwierigkeit 2/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
SKaiNET-developers/SKaiNET#1417 ·
Maintainer antworten meist innerhalb von 1 Tag
-
coding good first issue size:s skill:kotlin-core sub-issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
SKaiNET-developers/SKaiNET#1416 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in SKaiNET-developers/SKaiNET
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
intellij-elixir/intellij-elixir#4585 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
music-assistant/mobile-app#1298 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
-
core docs p3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
RunanywhereAI/runanywhere-sdks#1199 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100