Positive, negative, boundary and integration test cases: examples and a cheat sheet

Positive test cases check that a feature works with valid input. Negative test cases check that it rejects invalid input safely. Boundary test cases check values at the exact edges of what is allowed. Integration test cases check that the feature still works when it interacts with other parts of the system. A requirement is only well covered when it has the categories that apply to it, not just the happy path.

The cheat sheet

Category	Question it answers	Typical input	Expected result	Example (coupon field)
Positive	Does it work when used correctly?	Valid, typical values	Success	SAVE20 gives 20% off
Negative	Does it fail safely when misused?	Invalid, missing, malformed values	Clear error, no side effects	SAVE99 (unknown) shows an error, total unchanged
Boundary	Does it behave at the edges?	Min, max, and one step either side	Correct side of the rule	$50.00 cart applies MIN50; $49.99 does not
Integration	Does it hold up with the rest of the system?	Realistic multi-step flows	State stays consistent	Discount survives editing the cart

Positive test cases

A positive test case uses valid input and expects the feature to succeed. It proves the requirement works at all.

Examples:

• Login: a registered email and correct password signs the user in.
• Search: a query that matches products returns them.
• Form: a valid phone number is accepted and saved.

Positive tests are necessary but not enough. Most production bugs live in the inputs nobody expected.

Negative test cases

A negative test case uses invalid input and expects the system to reject it clearly, without side effects. Good negative tests check three things: the input is rejected, the user sees a helpful message, and nothing else changes (no charge, no saved record, no changed total).

Examples:

• Login: a wrong password shows an error and does not sign the user in.
• Coupon: an expired code shows "This coupon has expired" and the total does not change.
• Upload: a file over the size limit is refused before upload starts.
• API: a request with a missing required field returns a validation error, not a server error.

Ideas for negative inputs: empty values, wrong type (letters in a number field), too long, special characters, leading/trailing spaces, wrong case, duplicates, expired or revoked items, and actions without permission.

Boundary test cases (boundary value analysis)

Boundary value analysis tests the values at the edge of a valid range and one step on either side, because off-by-one mistakes (< instead of <=) cluster there.

For a rule "quantity must be between 1 and 100":

Value	Why	Expected
0	Just below minimum	Rejected
1	Minimum	Accepted
2	Just above minimum	Accepted
99	Just below maximum	Accepted
100	Maximum	Accepted
101	Just above maximum	Rejected

Boundaries are not only numbers. Test them for dates (expires today vs yesterday), text length (max characters), money ($49.99 vs $50.00), counts (the 10th item on a page of 10) and time (the second a session expires).

Equivalence partitioning: fewer tests, same coverage

Equivalence partitioning groups inputs that the system should treat the same way, and tests one value from each group. For the 1–100 rule there are three partitions: below 1, 1 to 100, above 100. One value from each, plus the boundaries, covers the rule without testing all 100 numbers.

Integration test cases

An integration test case checks that a requirement still holds when it works together with other components: another feature, a service, a database or a third-party API.

Examples:

• A discount still applies after the cart quantity changes.
• An order placed on the web shows up in the order history.
• A password reset email arrives and its link signs the user in.
• A payment declined by the provider leaves the order unpaid and the cart intact.

At the UI level, these are usually end-to-end tests that run through a real browser.

How many of each?

There is no fixed ratio. Use this rule of thumb per requirement:

1. At least one positive case per main path.
2. At least one negative case per way the input can be invalid.
3. Boundary cases for every numeric, date or length limit.
4. Integration cases for each place the requirement touches another feature.

Then check your coverage in a traceability matrix. A requirement with only positive tests is a coverage gap even if it has ten of them.

Generating categories automatically

Deciding which categories apply and listing the edge values is systematic work, which makes it a good fit for AI. In testdart, AI Genie generates positive, negative, boundary and integration test cases for each requirement you pick, and you choose the categories and can add an instruction to steer it. You can review the cases in copilot mode before they run in a real browser. See it on the product page, or read the full method in how to write test cases from requirements.

FAQ

Is negative testing the same as testing error messages? It includes error messages but is broader: a negative test also checks that the invalid action had no side effects.

Are boundary tests positive or negative? Both. The value at the boundary is usually a positive case; the value just outside is a negative case.

Do unit tests use the same categories? Yes. The categories apply at every level: unit, API and end-to-end. The examples here are end-to-end because that is where requirements are expressed.