Checking what a system should not do, not only what it should do. A negative test confirms that under defined conditions the system does not display, allow, or perform something, treating those constraints as a normal function of the system rather than as exceptional or wild and wacky edge cases.
So what? Framing tests as "should" and "shouldn't" (and tightening that to "does" and "doesn't") makes constraints explicit and gives stakeholders clearer certainty about how the system is intended to behave.
Examples: Confirming a basic account cannot see an admin panel; confirming a read-only field cannot be amended.
So what? Framing tests as "should" and "shouldn't" (and tightening that to "does" and "doesn't") makes constraints explicit and gives stakeholders clearer certainty about how the system is intended to behave.
Examples: Confirming a basic account cannot see an admin panel; confirming a read-only field cannot be amended.
