Ask the robots to not check error messages so explicitely (#402)

Co-authored-by: kmontemayor <kyle.e.montemayor@gmail.com>

Author: kmontemayor2-sc

.cursor/rules/testing-patterns.mdc

@@ -61,6 +61,38 @@ class TestWithAssets(unittest.TestCase):
         self.assertIn("edges", config)
 ```
 
+### Testing Errors
+
+Error cases *should* be tested, with `self.assertRaises`.
+Be careful when checking for error messages in the test case, as it makes it hard to update logs in the future.
+Some examples where we *should* check for error messages:
+
+```py
+# Example 1: Multiple errors - we should make sure we are raising when expected
+def foo():
+    # Check when bar fails
+    if not bar():
+        raise ValueError("bar() failed!")
+
+    # Check when baz fails
+    if not baz():
+        raise ValueError("baz() failed!")
+
+# Example 2: When the error message has load bearing use downstream - e.g. error reporting
+def qux():
+    if not some_check():
+        raise ValueError(f"Structured error: my/namespace/tries/10")
+```
+
+In all other cases, we should not be checking the exact error message.
+E.g. if the error message is formatted with the input:
+
+```py
+def assert_even(x: int):
+    if not x % 2:
+        raise ValueError(f"{x} is not even")
+```
+
 ### Integration Testing
 
 For integration tests that require cloud resources, add them to the `python/tests/integration` directory