How does Green compare to nose?

25 views
Skip to first unread message

Nathan Stocks

unread,
Jun 19, 2014, 7:48:05 PM6/19/14
to nose-...@googlegroups.com
If anyone would like to compare the test runner I wrote ( Green, https://github.com/CleanCut/green ) to nose, I would be interested in hearing your feedback.

Green originally started as a nose plugin, then I rewrote it as a nose2 plugin, and then I ended up rewriting it a _third_ time as a standalone test runner.  So, considering its roots, I thought it might be interesting to some people here to check out.

The biggest obvious difference is that I do not currently plan to ever support plugins.  So its a smaller, standalone runner.

~ Nathan

Tom Barron

unread,
Jul 9, 2014, 2:05:37 PM7/9/14
to nose-...@googlegroups.com
Hi, Nathan,

I find both nose and green useful.

Things I like about green:
  • The simple dotted syntax for specifying individual tests. Where with nose I have to say "dir/file.py:Class.test_name", with green it's just "dir.file.Class.test_name".
  • The colors are nice. I like seeing the green/red contrast.
  • Your tutorial on testing and project layout.

A nice thing about nose is its flexibility. I'm able to use it on a python 2.6 project where green requires 2.7. And plugins.

Looking through the green documentation, I don't see anything about green supporting a configuration file. I use the nose config file for things like making -v the default rather than having to type it every time. I suppose I could use an alias or a bash function to get a similar effect with green. Any thoughts?

I had been thinking of attempting to hack plugins into green. I'll stop thinking about that since you have explicitly stated that you don't intend to support plugins. :)

Tom

Roy Smith

unread,
Jul 9, 2014, 2:11:47 PM7/9/14
to nose-...@googlegroups.com
On Jul 9, 2014, at 2:05 PM, Tom Barron wrote:

Hi, Nathan,

I find both nose and green useful.

Things I like about green:
  • The simple dotted syntax for specifying individual tests. Where with nose I have to say "dir/file.py:Class.test_name", with green it's just "dir.file.Class.test_name".
I love it!  Killer feature.  Yes, thank you, thank you, thank you!

(sorry to get so excited, but really, that's nice)

Actually, what I've often thought nose needed was the ability to intuit the full path.  I should be able to say "nose test_blah", and it should do a full discovery and if there's only one test that matches "test_blah", just run it without my having to construct the full path to it.


---
Roy Smith



Nathan

unread,
Jul 9, 2014, 2:29:01 PM7/9/14
to nose-...@googlegroups.com
Tom,

It's always nice to hear what people think about green!

I agree, I really like the dotted syntax!  I'm working on resolving one outstanding bug* so that I can implement bash/zsh-completion** so then you can just go "green someth<TAB>" and help you tab-complete the dotted name.

The colors are why I started green in the first place, so I'm glad you like them!

This is the first feedback I have received on the tutorial.  I'm glad you liked it.  I wrote it because I have never found a guide that I felt explained test layout options properly, so it was partly just writing down the lessons I managed to learn so I can refer back to it myself.

Regarding support for older versions of Python, there are a couple places at work where we still use Python 2.6, and it stinks that I can't use green there -- I feel your pain.  That's not going to change, though, since the world is moving steadily to 2.7 and 3.x (yay for the RHEL/CentOS 7 release!).  I have looked at supporting older versions and it is _not_ pretty.

You are correct, green does not currently support a config file.  That would be a good feature to add.  In fact, I just went and added it to the list.***  For now, `alias green="green -v"` will work for you just fine, methinks.

Regarding -v specifically, I personally think -v ought to be the default level, instead of just dots.  So I am likely to change that in the near future.  I think the "just dots" output should be a special case of lesser verbosity.  Honestly, since just about every other python test runner I have ever seen defaults to the dots output, I felt pressured to do the same to start with, but I also use -v or -vv most of the time.  I haven't yet decided if I'm going to switch to a set of configurable output options (where you control different output features with individual flags), stick with the -v stacking, or do some hybrid.

Don't let my reluctance to support plugins stop you!  If nothing else, it is always fun for me to see other people's ideas in action.  I may be persuaded to support plugins someday, but it adds a lot of inertia to the project making it harder to change things -- so I will definitely not do it until I feel like I have exhausted core features and fixes that I want to implement.  I won't make any guarantees about whether I'll merge it back upstream, but I really like to see other people's take on my work.

Thanks for the feedback, Tom!

~ Nathan



--
You received this message because you are subscribed to the Google Groups "nose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nose-users+...@googlegroups.com.
To post to this group, send email to nose-...@googlegroups.com.
Visit this group at http://groups.google.com/group/nose-users.
For more options, visit https://groups.google.com/d/optout.

Nathan

unread,
Jul 9, 2014, 2:36:32 PM7/9/14
to nose-...@googlegroups.com
Roy,

Awesome!  I didn't realize people would notice that feature specifically.  I "grew up" using trial, which supported that feature, so I always considered it a normal base feature of a test runner (I mean, even unittest supports it).

Test-case-matching discovery.  Interesting feature!  I've never considered that one.  I'll have to keep that in mind as I re-implement test discovery on my own (it's the only sane way I can fix a bug* in green across all versions of Python -- I didn't _want_ to rewrite discovery!).  If it's not too messy, I may try to implement that.  It would probably need to be a separate option apart from "target", since "target" is meant to specify _where_ to look, and this would be _what_ to look for.  Maybe -f/--find would be a good name for it.
Reply all
Reply to author
Forward
0 new messages