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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
