Reads nine languages

  • Python
  • TypeScript
  • JavaScript
  • Java
  • C#
  • Rust
  • Ruby
  • Go
  • C

The Slop Audit · an open standard

Can your code ever be fully tested?

Paste a link to any public GitHub repo. We tell you one of three things: it can be fully tested, it might be, or it never can, and we show you why. A lot of AI-written code keeps shared data that can be almost anything; once that is true, no amount of testing can cover every case. Nothing is installed. We never run your code.

or

Here's a real result for our own code. Paste any public repo above to check yours.

Slop Audit result

openhonest/slop-audit

python
A 100% testable

Can this code ever be fully tested?

The grade is verifiability first, by a rule we publish rather than hide. The verdict sets the tier: CANNOT → F (some state is provably unbounded, so no finite test suite covers it), MIGHT → D (some state is undetermined). When every piece of state is finitely testable, the audit checks below decide A, B, or C by weighted health — god-files and type-escapes weigh most (3 each), then CI (2), then containers, pre-commit, and formatting (1 each). The number is the share of state that is finitely testable. No hidden weights.

This code definitely CAN be exhaustively tested.

930 test runs cover every path through the code, both sides of every yes-or-no. This is the whole list you would work through.

None of the data this code keeps can grow without limit, so a fixed number of tests can check every case. The Slop Audit worked out the fewest test runs that reach every path: 930 runs cover them all.

100% of its state is finitely testable

  • 0 testable
  • 0 unbounded
  • 0 undetermined

Can this code be verified?

The numbers behind the answer above. They carry no compliance tag on purpose: they set the ceiling on what every check below can ever prove.

  • 2017
    Decisions that could be exhaustively checked L1.19 · decision-space coverage
    No data

    How many decisions in the code (branches, lookups, and the like) could be listed and checked one by one. The share your tests actually reach is the real number, and getting it means running your test suite; the value here is n/a until that run measures it.

How it maps to your audit

Each row below is matched to the enterprise audit areas and the compliance controls they answer to.

  • 0.0/kloc
    Escapes from the type system L1.15 · type-escape density
    Clean

    How often the code opts out of its own type checker (any, # type: ignore, interface{}, dynamic) per thousand lines. Each escape is a spot the compiler can no longer protect, so a test has to cover it by hand.

    Counts toward Dependency injection · 4.12 NIST SA-11 · ISO/IEC 25010 (testability)
  • 0.0%
    “God-files”, files too big to hold in your head L1.17 · god-file concentration
    Clean

    The share of files over 1,000 lines, an AI smell. AI assistants pile new code into the biggest file they can find; without a reviewer forcing a split, these grow until every change touches them and merge conflicts multiply.

    Counts toward Tech-debt management · 4.17 NIST CM-8 / SA-15 · SOC 2 CC7.1 · ISO/IEC 25010
  • 0.0%
    Indications that a human ever edited the file L1.16 · trailing-whitespace density
    Clean

    Harmless on its own, but an AI smell: lines left with trailing whitespace mean no editor or formatter touched the file between 'the AI wrote it' and 'it landed on main', which usually means no human reviewed it either.

    Counts toward SDLC with AI safeguards · 4.16 NIST SA-3 / SA-8 · SOC 2 CC8.1 · OSFI B-13 §4.1.3
  • 5
    Automated build-and-test pipelines L1.10 · CI/CD pipelines
    Clean

    How many pipelines build, test, and gate each change before it ships. Zero means every merge is a manual act of faith.

    Counts toward CI/CD · 4.10 NIST SA-11 / SA-15 / CM-3 · SOC 2 CC8.1 · OSFI B-13 §4.7 · SSDF PW.7
  • present and parameterized
    A reproducible environment L1.11 · containerization
    Clean

    Whether the repo ships a container or orchestration config so it runs the same on every machine. The container is the constraint that keeps an AI's environment-coupling habits from becoming the classic 'it works on *my* machine.'

    Counts toward Containerization · 4.11 NIST SP 800-190 · SP 800-53 SA-11 / SI-7
  • present
    Checks that run before every commit L1.9 · pre-commit hooks
    Clean

    Whether automated checks run before code can even be committed, the first gate that catches AI output before a human ever sees it.

    Counts toward CI/CD · 4.10 + SDLC safeguards · 4.16 NIST SA-11 · SOC 2 CC8.1

Thread-safety surface clean

No concurrency escape hatches found. Nothing overrides or bypasses the language's own thread-safety guarantee.

This measures audit surface, not races. It shows where a language's thread-safety guarantee is overridden or missing, so a human or a runtime tool knows where to look. It does not detect data races: that needs ThreadSanitizer or an equivalent at runtime. A site here means "verify this", never "a race exists".

Scoped out of this audit: 2014 files not part of the library (48 tests, 1966 vendored). Docs, build and test tooling, and loose entry-point scripts are not the code under test. Everything set aside is listed so you can check it.

A full Slop Audit scores all 18 enterprise compliance dimensions and produces SOC 2 evidence as a byproduct. This page runs the static Layer 1 indicators only, and never executes the repo's code. That costs two of the twenty indicators: L1.19 shows how many decisions exist, not what share your tests reach, and L1.20, test determinism, is not shown at all. So this grade answers whether the code can be exhaustively verified, which is a property of how it is built, and not whether it is verified, which is a property of your test suite. A repository with no tests at all can score well here. Run the CLI to answer the other half.

What you're looking at

The top of the card is the answer: can this code be fully tested, yes, maybe, or no. Below it, each row is one thing we measured, matched to the audit checkboxes (SOC 2, NIST, OWASP, ISO) your reviewers already use.