Previously I have written custom error classes in Python and as long as they inherited from the right exceptions, they still passed the tests. Recently my submissions with custom errors have been failing tests about errors. Can you make the tests less strict?
- I’m pretty sure nothing changed recently here. The standard approach to testing exceptions is with the
assertRaises()method. Are you sure something changed? - Writing custom error classes isn’t necessarily good practice. Python’s standard library is pretty large and covers a lot of ground, and manages to do so with a relatively small number of shared exceptions. Introducing new exceptions adds additional complexity that often doesn’t have much value. (Granted, this is a subjective opinion on this topic and others might say custom error classes are a good thing. The tests do get to be subjective, though.)
@DocInDocs which exercise are we talking about here? Also, please post your code so we can look at it, Preferably in a code block:
```python
# this is a code block
print("Hullo!")
```
# this is how it looks when posted
print("Hullo!")
If the tests have recently been changed to be more strict about errors, then this was probably on purpose.
The change of checking for specific error messages was made at the end of 2021. Some of the reasoning behind the move is in this issue: [Practice Exercises] Add Guidance for Exercises that Require Raising Errors or Error handling · Issue #2563 · exercism/python · GitHub.
In the course of that change, we made sure (please let us know if we missed one!) that the exercise instruction appends explaining how to set up error handling included code showing the messages (as opposed to the type) that the tests were looking for. That way, students had an opportunity to copy them into their code, rather than hunt for them in the test cases.