I've heard that Nose is the new way to go. I've also used py.test in the past, because a friend suggested it. I know that both are both are considered better than unittest. I'm not too interested in getting deep into Nose because I get the feeling that it only serves Python. unittest, a xUnit implementation, seems more Acmeist.
I'm really only interested in programming ideas/projects that serve (or have the potential to serve) many languages. I've been calling this interest, Acmeism. In my upcoming seapig presentation about C'Dent, the central theme will be about Acmeism. Acmeism is more driven by social inclusiveness than by technological superiority. Python, Perl, PHP, Ruby spend all this time competing and crappy languages like Java and C# win out in job share. I feel like good ideas should be made to be shared across good languages. Also Acmeism is _not_ about everybody moving to one language. I think that would be about as disastrous as all people in the world speaking one natural language. Embrace cultural diversity, be true to your background, but realize that you are all really on the same side, so lend your Portugese/PHP speaking neighbor a helping hand... I'm really liking working in Python, but I have no interest in doing all my work in Python. I'm interested in getting all the OSCON language people in the habit of working together. I think a big point of intersection is _modules_. Modules encapsulate _ideas_. In general, they don't need to be tied to a language. I'm not certain that many people today share the Acmeist ideal, but it's what drives me as a programmer. I look forward to discussing it with y'all at the next meeting. Cheers, Ingy On Tue, Mar 30, 2010 at 12:28 AM, Mike Orr <[email protected]> wrote: > > On Mon, Mar 29, 2010 at 8:34 PM, Ingy dot Net <[email protected]> wrote: > > I want to learn unittest since it is core. Now I can tell people to run > > 'python setup.py test' or simply 'make test' and it will always do the right > > thing. > > I have a project called TestML that is a programming language agnostic unit > > test language. I'll be talking about it (along with C'Dent) at the upcoming > > meeting. > > Just because Unittest is core doesn't mean it's great. You may enjoy > learning it and it may help you understand Python, but the time it > requires has to be weighed against what you can accomplish with a more > capable test engine. There's a reason several projects have switched > to Nose, and it's because Unittest is so limited in test discovery and > so Javaesque in test structure. Nose has plugins! You can spend your > time writing a custom plugin for some esoteric feature, while it zips > along importing submodules for you. > > Supposedly the Unittest way to collect tests in submodules is for each > module to provide a function that returns a test suite; i.e., a > collection of all its test cases. Then you aggregate all those into a > compete suite and run it. That avoids calling unittest.main() in > every submodule. I think you can pass a test suite to the top-level > unittest.main()? > > That doesn't help with the importing step though. Parsing module paths > and using __import__() gives me the shivers, especially if I have to > recursively __import__() through packages or modify sys.path in an ad > hoc manner. But it can be difficult to get around it sometimes. > Alternatives include execfile and the various compile functions. > Python 2.7 / 3.2 has a bunch of Unittest enhancements; there might be > something for better discovery. > > > Cheers, Ingy > > PS. It turned out the setup.py only ran the first test, if I had multiple > > tests. That is because unittest calls sys.exit!! That seems evil to me. > > I think this was mentioned in the Unittest talk at PyCon, as something > fixed in the 2.7 enhancements. I may be wrong about that. > > > I > > was overjoyed to find out I could work around this with even more evil. I > > added this to my setup.py: > > def exit(code): > > pass > > sys.exit = exit > > At least you recognize that it's evil. > > -- > Mike Orr <[email protected]>
