Verify that swapping the operands of an addition operation does not change the result.

Assert that an operation is commutative, documenting an algebraic property in executable form.

When writing unit tests for numeric types, custom classes with __add__, or any domain where commutativity is expected.

Unit test suites, property‑based testing suites, educational examples of algebraic properties.

def test_<name>(<arg1>, <arg2>): assert <arg1> <op> <arg2> == <arg2> <op> <arg1>

def test_<name>(<params>): assert <expr>

a: any object supporting the + operator, b: any object supporting the + operator, function_name: identifier (e.g., test_add_commutes)

• assertEqual
• pytest
• unittest
• hypothesis
• property‑based testing

• Using assertEqual for clearer failure messages
• using != to test non‑commutativity
• substituting * for + to test multiplication commutativity.

Using assignment (=) instead of equality (==): cause: confusing assignment with comparison; consequence: SyntaxError. Omitting the assert statement: cause: forgetting to assert; consequence: expression is evaluated but the test passes regardless of the result. Using a non‑commutative operator (e.g., subtraction): cause: misunderstanding which operators commute; consequence: test fails incorrectly. Floating‑point equality without tolerance: cause: assuming exact equality for floats; consequence: false failures due to rounding errors. Incorrect test function naming (not starting with test_): cause: test runner ignores the function; consequence: test never executed.

test_associative: checks (a + b) + c == a + (b + c) – tests associativity rather than commutativity. test_distributive: checks a * (b + c) == a * b + a * c – tests distribution of multiplication over addition. test_identity: checks a + 0 == a – tests the identity element for addition.

Coming from C/Fortran: may assume floating‑point addition is exactly commutative; recall that rounding can break exact equality, so consider using a tolerance. Coming from Java: may prefer assertEquals(a+b, b+a) over plain assert; both work but assert gives less diagnostic detail. Coming from Haskell: may rely on type‑class constraints and forget to constrain the arguments to a Num‑like type, leading to type errors.

• test_associative
• test_distributive
• test_identity
• test_inverse

Do not use this test for non‑commutative operations such as subtraction, matrix multiplication, or string concatenation. The test has negligible runtime cost; the dominant cost is the operation being tested. For floating‑point numbers, exact equality can fail due to rounding; consider using math.isclose or a tolerance‑based assert instead of plain ==

Guards against subtle bugs in algebraic code and gives confidence that refactorings that rely on commutativity (e.g., reordering terms) will not change program behavior.

Think of addition as a dance where partners can swap places and still end up in the same spot – the result doesn’t change who they’re dancing with.

In property‑based testing frameworks like Hypothesis, this property can be expressed as a rule that holds for all generated inputs, increasing confidence beyond hand‑picked examples.

Move to property‑based testing with libraries like Hypothesis to verify the commutative property across thousands of random inputs.