Whoops, that should say "assertions" not "exceptions". ----- Original Message ----- > From: "Solly Ross" <sr...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Monday, November 24, 2014 12:00:44 AM > Subject: Re: [openstack-dev] [nova] Proposal new hacking rules > > Well, at least the message for exceptions in Nova says "expected" and > "observed". > I suspect that it's part of our custom test case classes. > > Best Regards, > Solly Ross > > > ----- Original Message ----- > > From: "Matthew Treinish" <mtrein...@kortar.org> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@lists.openstack.org> > > Sent: Friday, November 21, 2014 5:23:28 PM > > Subject: Re: [openstack-dev] [nova] Proposal new hacking rules > > > > On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote: > > > On 11/21/2014 01:52 PM, Matthew Treinish wrote: > > > > On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote: > > > >> Hey, > > > >> I am not a Nova developer but I still have an opinion. > > > >> > > > >>> Using boolean assertions > > > >> I like what you propose. We should use and enforce the assert* that > > > >> best > > > >> matches the intention. It's about semantic and the more precise we > > > >> are, > > > >> the better. > > > >> > > > >>> Using same order of arguments in equality assertions > > > >> Why not. But I don't know how we can write a Hacking rule for this. So > > > >> you may fix all the occurrences for this now, but it might get back in > > > >> the future. > > > > > > > > Ok I'll bite, besides the enforceability issue which you pointed out, > > > > it > > > > just > > > > doesn't make any sense, you're asserting 2 things are equal: (A == B) > > > > == > > > > (B == A) > > > > and I honestly feel that it goes beyond nitpicking because of that. > > > > > > > > It's also a fallacy that there will always be an observed value and an > > > > expected value. For example: > > > > > > > > self.assertEqual(method_a(), method_b()) > > > > > > > > Which one is observed and which one is expected? I think this proposal > > > > is > > > > just > > > > reading into the parameter names a bit too much. > > > > > > If you are using assertEqual with 2 variable values... you are doing > > > your test wrong. > > > > > > I was originally in your camp. But honestly, the error message provided > > > to the user does say expected and observed, and teaching everyone that > > > you have to ignore the error message is a much harder thing to do than > > > flip the code to conform to it, creating less confusion. > > > > > > > Uhm, no it doesn't, the default error message is "A != B". [1][2][3] (both > > with > > unittest and testtools) If the error message was like that, then sure > > saying > > one way was right over the other would be fine, (assuming you didn't > > specify > > a > > different error message) but, that's not what it does. > > > > > > [1] > > https://github.com/testing-cabal/testtools/blob/master/testtools/testcase.py#L340 > > [2] > > https://github.com/testing-cabal/testtools/blob/master/testtools/matchers/_basic.py#L85 > > [3] > > https://hg.python.org/cpython/file/301d62ef5c0b/Lib/unittest/case.py#l508 > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev