Phil Christensen wrote:

trial takes an argument at the command-line where you can specify a package or test case.

for example:

trial twisted trial twisted.test trial twisted.test.test_explorer trial twisted.test.test_explorer.TestBrowser trial twisted.test.test_explorer.TestBrowser.test_chain

lets you get more and more specific.

-phil

Sorry, I'm feeling dense. I currently run it as "trial MyServerTestFile.py"; it's not a package or part of one. In the file are several classes, each with several test cases. How would I adapt the above to my needs? -- Don Dwiggins Advanced Publishing Technology

Tim Allen wrote:

If you ran python in the same directory where you ran "trial" in your example, you could say:

import MyServerTestFile MyServerTestFile.MyServerTestCase.test_my_server

...to refer to a particular test method, and trial will accept the same syntax:

trial MyServerTestFile.MyServerTestCase.test_my_server

That's progress; thanks! It gives me a choice of running either all tests in a particular class, or one test. I could probably cobble up a shell or python script to wrap around it and allow me to run a list of "specs"; it'll be better than all the "foo"ing I've been doing. 8^) A quick thought: maybe I could use decorators on test methods to apply "tags" to my tests, then write a script to run all tests with a given tag; this might be even handier.

In general though, a lot of distribution and packaging and deployment things become easier if your project is laid out in Python packages. I usually follow these rules and everything turns out pretty well:

http://jcalderone.livejournal.com/39794.html

Good advice, if you're distributing a python library. In my case, the end result is an installer that creates a single .exe (a Windows service; frozen with py2exe) and a config.ini file. For me, there's no particular value in creating a package hierarchy just for testing. (With one possible exception: I may want to create a multi-level hierarchy of tests, rather than just the fixed file/class/method structure that unittest/trial gives you. -- Don Dwiggins Advanced Publishing Technology

On Aug 27, 2009, at 4:08 PM, Phil Christensen wrote:

On Aug 27, 2009, at 4:00 PM, Don Dwiggins wrote:

...

I've been successfully and happily using Trial for a while now for development of a server. I have many tests at this point; during development of a new feature, I'd like to have a convenient way to only run the tests relevant to that feature.

I'm hacking it at this point by prefixing the names of all unwanted tests with "foo" to keep them from being recognized. Naturally, I'd like a better way to do this. Any good words welcome.

trial takes an argument at the command-line where you can specify a package or test case.

for example:

trial twisted trial twisted.test trial twisted.test.test_explorer trial twisted.test.test_explorer.TestBrowser trial twisted.test.test_explorer.TestBrowser.test_chain

lets you get more and more specific.

Right, but, far as I can tell, you can only do one at a time. I just want to run the list of ones I know are working even though there are many more written and waiting to be pulled in and debugged (one at a time). IOW, I want to specify a list of tests to run out of many that match the file pattern. S