Python assertion statements should be clear and readable.
Should_dsl is an excellent library that allows Python programmers to write clear and readable should assertions with ease. This library aims to make the process of writing should assertions as close as possible to natural language, with examples such as "SOME_VALUE should be equal to ANOTHER_VALUE" or "SOME_EXCEPTION should be thrown by SOME_CALLABLE."
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.
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.
What's New
Version 1.2.1: N/A