We’ve added 13 new Python rules to help teams write clearer, more reliable tests and use Pydantic models safely.
The new testing rules encourage precise exception checks, parameterized tests for similar cases, one invocation when testing runtime exceptions, dedicated exception assertions, meaningful test files, and correct assertion usage.
For Pydantic, the new rules help avoid conflicting multiple-inheritance configurations, unsafe serialization without fallback handlers, unsupported json_schema_input_type usage, ambiguous private attribute names, and incompatible validation constraints.
New rules:
-
S5958: Tests should check which exception is thrown
-
S5976: Similar tests should be grouped in a single Parameterized test
-
S5778: Only one method invocation is expected when testing runtime exceptions
-
S8714: Dedicated exception assertions should be used instead of “try-catch” with “fail()”
-
S2187: Test files should contain at least one test case
-
S5863: Assertions should not be given twice the same argument
-
S3415: Assertion arguments should be passed in the correct order
-
S5779: Assertions should not be made within the try block of a try-except catching AssertionErrors
-
S8963: Pydantic models should not use multiple inheritance with conflicting configurations
-
S8966: pydantic-core serialization calls should provide fallback handlers
-
S8974: “json_schema_input_type” should not be used with “mode=‘after’” field validators
-
S8973: Double leading underscores should not be used for private attributes in Pydantic models
-
S8971: “SkipValidation” should not be combined with validation constraints
We’d love your feedback on other Python testing and Pydantic patterns we should cover next.