Hmm, it is too. I always preferred creating expectations before the mock is used rather than use assertions after.
However, I just looked at mock and it does look a lot more powerful (I can't remember what it was like when I started using fudge several years ago). And fudge doesn't seem to have been active for quite a long time. Stephen. On Aug 23, 2013 7:10 AM, "Rory Hart" <[email protected]> wrote: > Why fudge over Mock, with Mock in the python 3 stdlib? > > On 22/08/2013, at 11:57 PM, Stephen Moore <[email protected]> wrote: > > > That testtools thing looks pretty interesting, I haven't seen that > before... > > > > As for more suggestions, > > > > I tend to make my tests with classes based inheriting from > unittest.TestCase > > Using nose for test discovery and plugins like my noseOfYeti plugin > > https://noseofyeti.readthedocs.org/en/latest/ > > And fudge for mocking http://farmdev.com/projects/fudge/ > > > > Also, I haven't used it, but tox looks pretty cool > > http://codespeak.net/tox/index.html > > > > Stephen. > > > > On Thu, Aug 22, 2013 at 2:15 PM, Ben Finney <[email protected]> > wrote: > >> Rasjid Wilcox <[email protected]> writes: > >> > >>> To date I've mostly used Nose for my unit testing, but was just > >>> wanting to canvas views on what the current state of the art in Python > >>> testing is, and if I should be looking at something else. > >> > >> I use Python 2.7, or Python 3, and use the standard library ‘unittest’ > >> along with ‘testtools’ <URL:http://testtools.readthedocs.org/> > >> and ‘testscenarios’ <URL:https://pypi.python.org/pypi/testscenarios>. > >> > >> The ‘unittest’ library in Python's standard library has been > >> significantly improved. Developers using Python 3 get the full benefits, > >> but Python 2.7 also had many of the improvements back-ported. > >> > >> * Test case discovery > >> * Specify test cases from command line > >> * More assertion methods, more comparison methods > >> * ‘assertRaises’ as a context manager (for ‘with’) > >> * Adding cleanup functions > >> * Skipping tests conditionally > >> * Class-level and module-level fixtures > >> * etc. > >> > >> Michael Foord was a primary developer and advocate of these > >> improvements. Here is his description from 2011 > >> <URL:http://www.voidspace.org.uk/python/articles/unittest2.shtml>. > >> > >> All those improvements, along with the wonderful author-defined Matchers > >> in ‘testtools’ and the data-driven testing from ‘testscenarios’, I > >> virtually have no need of anything more than those. > >> > >> And they're easily accepted by my team, whereas switching to a different > >> test framework would be (correctly) met with much more resistance. > >> > >> -- > >> \ “Sunday: A day given over by Americans to wishing that they | > >> `\ themselves were dead and in Heaven, and that their neighbors | > >> _o__) were dead and in Hell.” —Henry L. Mencken | > >> Ben Finney > >> > >> _______________________________________________ > >> melbourne-pug mailing list > >> [email protected] > >> http://mail.python.org/mailman/listinfo/melbourne-pug > > _______________________________________________ > > melbourne-pug mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/melbourne-pug > _______________________________________________ > melbourne-pug mailing list > [email protected] > http://mail.python.org/mailman/listinfo/melbourne-pug >
_______________________________________________ melbourne-pug mailing list [email protected] http://mail.python.org/mailman/listinfo/melbourne-pug
