I was poking around with Selenium and wanted to write some assertions about a page not being a 404. I did a quick Google search, and came upon a thread where a maintainer kept pressing people for “a valid use case” for adding an explicit method to test HTTP response codes. His logic being that one could test for various page elements to see if it’s a 404 or not.
Still no meaningful use case has been provided. Instead of checking the HTTP response you should make assertions on the content of the page - this is what the user faces and not the codes.
This is true. One could check DOM elements to see if the page was found, but it feels better to have a simple yes or no answer to “Is the page even there?”.
Doing it the current way might look like this, where your company’s pages have h1’s with class “logo”.
assert(selenium.is_element_present("//h1[@class='logo']"))
This is perfectly ok, but it’s little tricky to know exactly what’s going on. My brain reads that as “Check to see if our (hopefully) universal h1 class value appears on the page, and if it does, assume it’s not a 404.”
Here’s what the same assertion might look like, but using the requested function from the thread:
assert(selenium.status_is_not(404))
This is much cleaner and more expressive: “if it’s a 404, fail the test. Don’t bother checking anything else”.
They’re both a single line, and not too complicated, but the second version feels better. It expresses the idea more clearly.
Writing code is communication. The tough part is that we write for machines and people at the same time. I think it’s a good idea to throw humans the occasional bone, and make things as humane as possible.
