CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/negative-test-generator

Generates negative / error-path test cases that mirror happy-path tests - for each happy-path test, produces companions exercising input validation rejection, missing required fields, type mismatches, authorization failures, rate-limit errors, and adversarial payloads from the malicious-payload-bank. Emits cases as parameterized tests in the project's runner format. Use when a feature has happy-path coverage but the rejection / error / unauthorized paths are untested.

97

Quality

97%

Does it follow best practices?

Impact

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

criteria.jsonevals/scenario-2/

{
  "context": "Rejection-path coverage for a request handler that already has a happy-path test. Predicted baseline failure: the agent adds a handful of negative cases but asserts them loosely - `assert.notEqual(status, 201)` or `assert.ok(response.body.errors)` - which passes just as happily when the handler returns 500, the precise regression the team described. The skill's value is that every negative case pins an exact status and an exact structured error field, and that the categories are enumerated rather than sampled.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Test file created",
      "description": "A file src/createProject.test.js exists and contains at least one test.",
      "max_score": 4
    },
    {
      "name": "Exact status asserted on every negative case",
      "description": "Each rejection case asserts a specific numeric status - 400 for validation, 401 for authentication. Any case asserting only that the status is not 201, or only that it is 'an error', scores zero on this criterion: such a test passes on a 500 and cannot catch the regression described in the task.",
      "max_score": 26
    },
    {
      "name": "Structured error field asserted, not message text",
      "description": "Cases assert the specific error key and code - for example body.errors.name equal to TOO_LONG - rather than the presence of an errors object or a substring match on prose. Asserting only that `errors` exists, or matching on message text, scores zero here.",
      "max_score": 20
    },
    {
      "name": "Missing-field cases covered",
      "description": "Both required-field omissions are covered: an absent ownerId and an empty or whitespace-only name, each asserting REQUIRED.",
      "max_score": 12
    },
    {
      "name": "Type-mismatch case covered",
      "description": "At least one case supplies a name of the wrong type - number, null, object, array - and asserts NOT_A_STRING. Omitting type mismatches entirely scores zero: it is the most common validator defect class.",
      "max_score": 12
    },
    {
      "name": "Both authentication branches covered",
      "description": "A missing authorization header and a present-but-wrong token are covered as separate cases asserting MISSING_TOKEN and INVALID_TOKEN respectively. Covering only one caps this at half.",
      "max_score": 10
    },
    {
      "name": "Enum rejection covered",
      "description": "A case supplies an unsupported visibility value and asserts UNSUPPORTED.",
      "max_score": 8
    },
    {
      "name": "One test per category",
      "description": "MUST NOT collapse the rejection paths into one test containing many assertions. Cases are separate tests or generated per-case, so a single failure identifies which category broke. A single mega-test scores zero here.",
      "max_score": 8
    }
  ]
}

SKILL.md

tile.json