On Wed, Jul 16, 2008 at 2:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> If some people want to proceed down the path of "useful additions", >>> I challenge them to think bigger. Give me some test methods that >>> improve my life. Don't give me thirty ways to spell something I can >>> already do. > > From: "Michael Foord" <[EMAIL PROTECTED]> >> >> I assert that... the following changes do meet those conditions: >> >> assertRaisesWithMessage > > . . . >> >> Changes to assertEquals so that the failure messages are more useful > > ... >> >> assertIn / assertNotIn I use very regularly for collection membership > > - self.assert_(func(x) in result_set) > + self.assertIn(func(x), result_set) > > Yawn. The gain is zero. Actually, it's negative because the second > doesn't read as nicely as the pure python expression.
It's only negative if the method doesn't do anything special. For example, an assertListEqual() method can tell you *how* the lists differ, which the pure Python expression can't -- all the Python expression can say is "yes" or "no". We have methods like this at work and they're very useful. That said, I see no reason why these things have to be methods. The self. method boilerplate is cluttering line-noise in this case. I can easily imagine a module of nothing but comparison functions. Collin Winter > Think bigger! No fat APIs. Do something cool! Checkout the > dynamic test creation in test_decimal to see if it can be generalized. > Give me some cool test runners. Maybe find a way to automatically > launch pdb or to dump the locals variables at the time of failure. > Maybe move the "test_*.py" search into the unittest module. > > We want *small* and powerful. The api for TestCase instances is > already way too fat. See an old discussion on the subject at: > http://bugs.python.org/issue2578 > > >> The run_tests function for running collections of tests. Almost every >> project I've worked on has had an ad-hoc imnplementation of this, collecting >> test modules and turning them into a suitable collection for use with >> unittest. > > Now, that's more like it. Propose more cool stuff like this and > the module really will be improved. > > >> assertIs / assertIsNot also sounds good, but is not something I would miss >> if they weren't added. > > Doh! We're back to replacing clean expressions using pure python syntax > with a method name equivalent. That's a step backwards. > > > > Raymond > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/collinw%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
