On 8/29/07, Chris H. <[EMAIL PROTECTED]> wrote: > > I'm a huge testing nut and there are some short cut/helper functions > we use at work that I'd like to clean up and contribute if folks are > interested.
We're always interested in contributions! :-) > The first is a simple method on TestCase that makes checking a normal > view pretty dirty simple... here's the signature: > check_response(self, response, template_name=None, text_checks=[], > content_type="text/html") .. > It's not rocket science, it just takes a 2 or 3 line self.assertX, > self.assertY call and makes it a one-liner. I like DRY and I like > testing, so this seemed to be a good fit. If I'm understanding your proposed method, I'm -1. Yes, it reduces code repetition, but it does so at the cost of legibility. Three separate assert calls makes it very clear exactly what is being asserted - return code, content, template, etc. This approach tries to combine an entire view test into a single function call. I can't speak for your tests, but for me, anything other than a trivial test involves mutiple content checks, multiple template checks - hardly something that I want to cram into a single line (or split line) of code. Lumping multiple tests into one also means that you have to decide upon 'the one true view test'. You have included a template and content test. Someone else may want to check the context, but not the template. Someone else may want to validate the response code. It will be nearly impossible to determine a common set without including _everything_, which will only make the method even more unwieldy. Again, in my tests, each test is slightly different - the idea that there is a single function that would test everything doesn't match with my experience. Personally, I don't see assertions repeated over multiple test cases as a violation of DRY - its the clearest possible and most flexible mechanism for expressing exactly what needs to be tested on a per-test basis. > If folks are interested I can supply a diff/patch on test case as well > as tests for the assertion/check_response methods. Should I supply > that in a ticket? This would be the normal approach - a ticket containing a patch against the current trunk, including documentation and test cases. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
