-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional assert methods for unittest #71339
Comments
Proposed patch adds the ExtraAssertions mix-in that provides additional assert methods. These methods provide better failure report than assertTrue/assertFalse with a result of corresponding function. For example assertStartsWith outputs shorten reprs of the start of the string and prefix. These checks are quite popular and can be used tens or hundreds times in tests (the patch makes tests using new assert methods): assertHasAttr 121 times |
Additional statistics that proves that specified checks are not specific for narrow group of tests: assertHasAttr 121 times in 57 files |
Why a mixin? (As an aside, there is a proposal to move all assert methods to a place where they can be accessed outside test cases.) |
I have this proposal (bpo-19645) in mind. We can add these method just in TestCase. In any case I'm going to add the ExtraAssertions mixin in test.support in maintained versions to help keeping branches in sync. |
I don't really like the assertEndsWith method which triggers a mental hiccup when taking a familiar method call, making it into function call, and giving an awkward looking camelcase name. Also, Guido is usually opposed to broad, sweeping search/replace patches. Instead, he has advocated "holistic refactoring" where updates are done by someone actively working on the module rather than a disinterested party churning the code without thinking deeply about the topic at hand. |
Changes in tests are provided as a demonstration that these methods are useful. I propose to commit only the unittest part, and use new methods on a case-by-case basis. For example some tests already define methods like assertHasAttr or assertIsSubclass, They can now use standard methods. assertEndsWith() can be used 73 times in 36 files. It produces more useful error report than assertTrue(a.endswith(b)). |
Why a mixin rather than adding to TestCase? If they are useful they should be easy to find. Also, see bpo-27198 for another possible new assert. |
I'm fine with these as a mixin - they are all very generic and unambiguously named. I'd marginally prefer the opt-in mixin over adding them to the base class. Ideally they'd be matchers, but since I haven't ported that upstream yet, thats asking for more work, and we can always migrate later. (https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers - sorry about the formatting in the blog post, wordpress changed theme details some time after I wrote the post and it now renders horribly :( ) |
Ask five people to spell "assertEndsWith" and see how many of them capitalize the "W". |
I would expect it to be assertEndswith, etc. You will note that all the other cases of multiple capitals are either englishification of symbolic operators or concatenations of separate type words and/or syntactically distinct operators. |
In particular assertStartsWith and assertEndsWith (and Not variants) are its simplest addition. I "only" see those used 2-3000 test files in our huge internal codebase which puts it in a <10% use them category. Their goal is to provide a nice error message, it does that. Those 2-4 would be trivial additions with no maintenance burden. (I'd go with 2, the negative Not variants see almost no use in practice). Outside of the stdlib I assume As for the method name spelling, anyone typing it wrong gets a failure immediately so that isn't a big deal, rapid feedback when wrong. They're fully consistent with the junit javaCaseStyle of unittest assertion methods with words delineated by a case change. |
+1 to assertStartsWith and assertEndsWith, they sound useful |
|
Hi, y'all. Just to keep things narrowly-scoped and specific, what would it take to get |
A PR adding those two and relevant unittests. |
Add the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartswith() and assertNotStartswith() * assertEndswith() and assertNotEndswith() Also improve error messages for assertIsInstance() and assertNotIsInstance().
#128707 is based on my old patch. The differences:
|
Since there are different opinions about names, I created a poll: https://discuss.python.org/t/assertstartwith-vs-assertstartwith/76701. @rhettinger and @bitdancer, please participate. |
Support for |
If you merge it early tomorrow, we will included it in 3.14.0a4 :) |
Add the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartsWith() and assertNotStartsWith() * assertEndsWith() and assertNotEndsWith() Also improve error messages for assertIsInstance() and assertNotIsInstance().
…honGH-128707) Add a mix-in class ExtraAssertions containing the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartsWith() and assertNotStartsWith() * assertEndsWith() and assertNotEndsWith() (cherry picked from commit 06cad77)
#128815 backports new assertion methods as a mix-in class in test.support. This will help to backport future tests that use these methods. |
…-128707) (GH-128815) Add a mix-in class ExtraAssertions containing the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartsWith() and assertNotStartsWith() * assertEndsWith() and assertNotEndsWith() (cherry picked from commit 06cad77)
…t.support (pythonGH-128707) (pythonGH-128815) Add a mix-in class ExtraAssertions containing the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartsWith() and assertNotStartsWith() * assertEndsWith() and assertNotEndsWith() (cherry picked from commit c6a566e) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> (cherry picked from commit 06cad77)
Fix test_cmd_line. Remove redundant msgs. Move some changes out to other PRs. Fix test_cmd_line again.
…-128707) (GH-128815) (GH-129059) Add a mix-in class ExtraAssertions containing the following methods: * assertHasAttr() and assertNotHasAttr() * assertIsSubclass() and assertNotIsSubclass() * assertStartsWith() and assertNotStartsWith() * assertEndsWith() and assertNotEndsWith() (cherry picked from commit c6a566e) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com> (cherry picked from commit 06cad77)
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: