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
More intuitive http response assertions #86
Comments
I like this idea as long as we keep the ones we have for backward compatibility. That way we can have the best of both worlds (I tend to think in the numbers not names, but I'm sure I'm probably in the minority there) |
@frankwiles, I think it's cool to keep the old ones around. If the project was new I probably would want to change them to assertHttp200, assertHttp302, etc. for consistency and to match the test case pattern. At some point it might be worth considering deprecating and then removing old methods as some point. Just "thinking out loud" :) |
Want me to contribute a PR? |
Yep that would be great! |
Added a PR, let me know what you think. |
We were talking about this earlier and are struggling with having 2 or 3 names for the same methods. I think filling in any missing status codes is valid, but I'm not sure how to resolve us wanting to keep backward compatibility while trying to keep the API clean. Moving from |
@jefftriplett and @frankwiles, What about keeping all the existing assert methods and then going forward use a hybrid solution that the Django Rest Framework uses where they have both the error code number and a slug of what the status code is. The new assert methods would like the following?
The benefit would be that if you're using an IDE you could find the method by either the number or name. This also has the added benefit of helping those that are new to the status codes of learning the number and what the meaning is behind the number. |
@epicserve I like that idea a lot. It fits my brain better, and we still have to have backward compatibility either way. I'll defer to the others to see what they think. |
yeah if we can keep |
@frankwiles and @jefftriplett, Do you want me to make a PR based on what has been outlined? |
@frankwiles and @jefftriplett, I went ahead and created a new PR. If it looks good, let me know and I can update the README as well. |
I created a PR for the readme updates. Once merged, we can close this issue. |
Any change we could get the readme changes merged in and a release made? I have a project I would like to update with the changes made in this issue. |
Done! I'm going to add a ticket for myself to re-add in the older |
Thank you for merging that in. I sort of wish now that you would have said you didn't want this contribution because I'm not a fan of having two ways to do things. That feels less pythonic and seems to go against, "There should be one-- and preferably only one --obvious way to do it." |
I've been thinking it would be better to make
assert
methods for http status codes instead of the currentresponse_XXX
pattern.Rational:
For example we could add the following:
The text was updated successfully, but these errors were encountered: