Opened 17 months ago
Closed 11 months ago
#34658 closed New feature (fixed)
New assertion `assertNotInHTML`, like `assertContains` has `assertNotContains`
Reported by: | Thibaud Colas | Owned by: | Nicolas Lupien |
---|---|---|---|
Component: | Testing framework | Version: | |
Severity: | Normal | Keywords: | testcases, unit tests, HTML, assertions, testing |
Cc: | Lemuel Sta Ana, Nicolas Lupien | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django’s test assertions have assertContains
and assertNotContains
which are HTML-aware ways to check what’s inside a response, similar to Python’s assertIn
and assertNotIn
. Django also offers assertInHTML
– but there is no assertNotInHTML
.
This is very straightforward to implement – and I suspect more than a few projects will already have their own implementation if they need this, but I think it’d make much more sense to have this out of the box considering other "<needle> in <haystack>" assertions have their -not
equivalent built in. For me, the main source of pain here is that I use this often enough to use this but rarely enough to frequently forget:
- Whether this is a Django built-in or not. So I look at assertions docs and am surprised not to see it.
- Whether the project I work on has it or not. So again I have to look around and potentially add it.
Change History (11)
comment:1 by , 17 months ago
comment:2 by , 17 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm skeptic. Personally, I find the use of *NotIn*
assertions really rare and not the best practice. There can many many reasons why something is not in something else, and it becomes even more unreliable when we do this in HTML. It's much more stable and bulletproof to use *In*
assertions. I don't think it's worth adding.
Please first start a discussion on the DevelopersMailingList, where you'll reach a wider audience and see what other think, and follow the guidelines with regards to requesting features.
comment:3 by , 17 months ago
Sorry about that, I thought I had read the ticket creation guidelines to check what the protocol is, but clearly missed the most important bits.
comment:4 by , 17 months ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
Accepting based on the discussion.
Thibaud, would you like to prepare a patch?
comment:5 by , 17 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Yes please! Omg I might eventually become a code contributor.
comment:6 by , 14 months ago
Cc: | added |
---|
Adding myself as CC, I'm very interested to see how the patch for this will be implemented. Hope you don't mind Thibaud.
comment:7 by , 12 months ago
Owner: | changed from | to
---|
comment:8 by , 11 months ago
Cc: | added |
---|---|
Has patch: | set |
comment:9 by , 11 months ago
Needs documentation: | set |
---|---|
Owner: | changed from | to
Patch needs improvement: | set |
comment:10 by , 11 months ago
Needs documentation: | unset |
---|---|
Patch needs improvement: | unset |
Triage Stage: | Accepted → Ready for checkin |
I fully agree with the rationale, but for this, perhaps, Thibaud could you please create a forum post to allow for people to present any counter argument we may not be considering?
Thanks!