APromptAura

#testing

Top prompts tagged testing.

0
p/metaAauraNovice4 days agohas example⁂auto-checked

Build a targeted edge-case test suite for a prompt before trusting it

Build a test suite of edge-case inputs for this prompt before I rely on it in production: prompt for task_description. Don't just give me random varied inputs, derive the edge cases from the prompt's actual logic. Requirements: 1. Read the prompt's conditional instructions (any 'if X, do Y, otherwise do Z' logic) and generate at least one test input for each branch, plus one input that sits right at the boundary between branches, since boundaries are where prompts most often misfire. 2. Generate inputs that test what happens when the prompt's assumptions are violated (it assumes the input will always contain a date, what if it doesn't; it assumes a single item, what if there are zero or many). 3. Generate one adversarial-but-realistic input (not a malicious attack, just a real-world messy input: contradictory information, missing context, informal phrasing) since production inputs are messier than clean test cases. 4. For each test input, state what the correct output SHOULD be and why, based on the prompt's stated logic, so this suite can actually be used to check pass/fail, not just to eyeball outputs. 5. Organize the suite as a table: Input, Expected Behavior, What It Tests. Prompt: prompt Task description: task_description
ClaudeGPT#testing#edge-cases#prompt-engineering
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Generate high-value unit tests for existing untested code, not filler

Write unit tests for the function/class below in framework. I don't want boilerplate happy-path-only tests. For each test you write, briefly state (as a comment) what specific risk it guards against. Cover, in priority order: 1. Boundary conditions implied by the code (off-by-one ranges, empty collections, first/last element behavior). 2. Error paths: every raised exception or returned error should have at least one test that triggers it deliberately. 3. State mutation correctness if the function has side effects: assert the state after, not just the return value. 4. Any branch in the code that isn't exercised by the boundary/error tests above, so coverage isn't accidental. 5. Skip tests that would just restate the implementation (e.g. mocking every internal call so the test can't fail even if logic changes) - flag anywhere the code's structure makes it hard to test meaningfully without a refactor, instead of writing a fake test. Code: code Existing test file (if any, so I don't get duplicates): existing_tests
ClaudeGPT#testing#unit-tests#coverage
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Write a regex with an explanation and a battery of test cases

Write a regular expression that matches: pattern_description Flavor/engine: {{regex_flavor, e.g. PCRE / Python re / JS RegExp}} Requirements: 1. Show the regex itself first, then a plain-English breakdown of each group/token, no jargon without explanation. 2. Provide a table of at least 8 test strings: half that should match (including tricky edge cases within scope) and half that should NOT match (including near-misses that a naive regex would wrongly accept), with the expected result for each. 3. State explicitly what the regex deliberately does NOT handle, if the description implies edge cases that would make the pattern unreadable to cover (e.g. fully RFC-compliant email addresses). 4. If a non-regex approach (e.g. a proper parser) would be meaningfully more correct for this task, say so, but still provide the best-effort regex if I asked for one. 5. Avoid catastrophic backtracking; note any risk points if the pattern uses nested quantifiers.
ClaudeGPT#regex#pattern-matching#testing
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Generate property-based tests that find edge cases, not happy-path duplicates

Write property-based tests (using {{framework, e.g. Hypothesis / fast-check / QuickCheck}}) for the function below. Do not write example-based tests that just restate the happy path; instead: 1. Identify the invariants the function should always satisfy (e.g. idempotence, round-trip, monotonicity, commutativity where applicable) and encode each as a property. 2. Identify the input domain's edge cases (empty, single-element, max/min values, unicode, negative numbers, duplicates) and make sure the generator can produce them, don't hand-pick a few examples. 3. For any invariant you're not confident actually holds, say so explicitly and mark the test with a comment explaining what you'd expect to see if it fails, rather than silently writing a weak assertion. 4. Keep generators realistic to the function's actual input contract, not maximally adversarial if that's outside the documented contract. Function: code Language: language Known contract/docstring: contract
ClaudeGPT#testing#property-based-testing#edge-cases
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Root-cause a flaky test using a structured hypothesis funnel

This test fails intermittently, not on every run. Help me find the actual root cause instead of just adding a retry or a sleep. Work through this funnel and show your reasoning at each step: 1. List every source of non-determinism visible in the test and the code it exercises (ordering, timing, shared state, randomness, network, concurrency, uninitialized globals). 2. Rank them by how likely each is to explain the specific failure signature I give you. 3. For your top hypothesis, propose the smallest possible experiment (a log line, an assertion, a seed) that would confirm or rule it out, without changing behavior. 4. Only after that, propose a fix. Explicitly say why a sleep/retry would mask this rather than fix it, if that's what's tempting. 5. If the fix requires changing production code (not just the test), flag that clearly since it has broader blast radius. Test code: test_code Code under test: code_under_test Failure signature (error, stack trace, how often it fails): failure_signature
Claude#debugging#testing#flaky-tests
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Turn a god function into composable, testable units

I have a function that has grown too large and does too many things. Refactor it into smaller, single-responsibility functions or classes, following these constraints: 1. Preserve the exact external behavior and public signature unless I say otherwise. 2. Extract pure logic (no I/O, no side effects) into its own functions first, so they can be unit tested without mocks. 3. Name each extracted piece for what it does, not how it does it. 4. Show the before/after side by side for the riskiest extracted piece, with a one-line note on why it is now safer to change. 5. List any behavior that is ambiguous in the original code (e.g. unclear error handling, implicit ordering dependencies) that I should confirm before shipping this refactor. 6. Do not introduce new dependencies or design patterns beyond what the language's standard idioms support. Language/framework: language Function to refactor: code What it's used for / calling context: context
ClaudeGPT#refactoring#clean-code#testing
0