Python assertion statements should be clear and readable.
To use this DSL, one needs to import the entire module's namespace using "from should_dsl import *." Once imported, one could write code like "1 |should_be.equal_to| 1," which will be true, or "'should' |should_have| 'oul'," which will also be true. If the code does not satisfy the assertion, an exception will be raised. For instance, the code "3 |should_be.into| (0, 1, 2)" will raise a ShouldNotSatisfied exception.
Moreover, the equal_to matcher checks for object equality. When one wants to ensure the identity of objects, they can use should_be with no matcher, such as in "2 |should_be| 2."
Should_dsl also handles exceptions, and to verify if an exception is raised as intended, one could write code like "ZeroDivisionError |should_be.thrown_by| raise_zerodivisionerror."
Additionally, both should_have and should_be have versions for negation. For instance, "2 |should_not_be.into| [1, 3, 5]" will be true, whereas "'should' |should_not_have| 'oul'" will raise a ShouldNotSatisfied exception.
Should-dsl is incredibly extensible, and users can extend the DSL with custom matchers easily. One can define custom matchers with the decorator @matcher, such as in the example "def the_square_root_of(): import math return (lambda x, y: x == math.sqrt(y), '%s is %sthe square root of %s')."
Finally, should-dsl is unittest-compatible, meaning that failures on should expectations will result in unittest failures, not errors. This ensures that the tests' outcome is more explicit, making debugging easier.
Version 1.2.1: N/A