7 comments

• 

  Stan

  1 year ago

  --pdb-failures is extremely useful for introspecting objects right when a unit test fails. Usually I can figure out what went wrong pretty quick thanks to this.
  
  I also use nose to drive twill-based website unit tests:
  (not sure how well this will paste)
  
  # test.py
  import twill, glob
  from StringIO import StringIO
  from nose import with_setup
  
  def setup():
  outp = StringIO()
  twill.set_output(outp)
  
  def run_twill(twill_file):
  script = file(twill_file).read()
  twill.execute_string('reset_browser')
  twill.execute_string(script)
  
  @with_setup(setup)
  def test_twill():
  for filename in glob.glob('*.twill'):
  yield run_twill, filename
  ### EOF
  
  Now you can put all of your website tests into .twill files in the current directory. I suppose this could be made into a nose plugin...
  reply
• 

  Stan

  1 year ago

  Well, all of the indenting was lost, but you get the idea.
  reply
• 

  Terry Peppers

  1 year ago

  Man, where do I start? Since my team uses it mainly for testing web interfaces - here's some things:
  
  Test generators are pretty key us. The same feature is in py.test - we use that feature of nose constantly on our team here @ work.
  
  The plugin architecture has also allowed us to be more flexible in what we can pass to our functional tests. We build custom plugins to allow more flexible test collection and execution.
  
  The underlying system of test collection is what has always attracted me. nose, in general, allows me to very quickly put together a suite of tests without have to deal with UnitTest boilerplate.
  reply
• 

  Kumar McMillan

  1 year ago

  I recently discovered the builtin plugin --with-id and can't believe I ever lived without it. When it's enabled you get numbered tests so you can re-run individual ones by saying `nosetests 23 45` instead of typing out long path names.
  
  I also miss nosetty, a plugin I wrote a while ago for 0.9 but have yet to port it to 0.10. Quite a lot has changed in stream handling and I started the migration but didn't finish. It was nice because it let you launch an editor at the exact spot in a traceback, especially nice if you need to apply a quick, experimental patch to a system egg.
  
  I also use NoseGAE for testing Google App Engine webapps in-process: http://code.google.com/p/nose-gae/
  
  btw, the official (unofficial?) list of all nose plugins is here: http://nose-plugins.jottit.com/
  reply
• 

  will

  1 year ago

  I used the spec plugin that comes with Pinocchio. At a minimum, it pushes me to write tests that focus on "invariants" of the things being tested.
  reply
• 

  waltercruz

  1 year ago

  Well, I have a little plugin not yet published, nose-notify. It uses the gnome notify system, but can be implemented with growl on Macintosh.
  
  http://www.assembla.com/wiki/show/nose_notify
  reply
• 

  programmer.py

  1 year ago

  I don't know if it's considered a plugin, but using --with-coverage and --cover-package (you'll need the coverage module), is great for finding gaps in testing.
  reply