That is unittest.main() trying to parse the arguments on the command line. Web2py is passing the original command line (sys.argv) to the unit test script, which sees the arguments for web2py.py and says "I don't know what these mean". A quick hack to gluon/shell.py ("sys.argv = sys.argv[4:]" on line 165 in web2py version 1.74.6) got me past this. Is there a clean, reliable way to not pass scripts all of the web2py.py CLI arguments?
Once I hacked shell.py I ran into another problem: the unittest module has the scope of web2py.py and not my script. Stepping through the unittest module code reveals that whenever unittest.main() tries to find the default test, or a test you specify, or tries to run all tests, it sees itself as being in "module '__main__' from 'web2py.py'". since web2py.py doesn't contain any tests the unittest sees nothing to do, and quits. If you named a specific test to run, the unittest module throws an exception and complains that such a test does not exist. How could this scoping issue be solved? unittest.main() takes a 'module' argument but I don't know what to put there to make it work. Thadeus, I found the web2py.py help string for "-R" misleading; when I run unit tests I don't want to launch a shell, and since the help string says "-R" requires the shell option, I concluded that "-R" was not what I needed. Also, AlterEgo 213 gives no indication that the sample unit test script should be run with web2py.py. Rather, it looks like a perfectly ordinary script that would be run with "python test.py". AlterEgo 213 further misleads by showing the user how to set up the web2py environment inside the unit test script, rather than relying on web2py.py to set it up. Once I get unit tests working I'll gladly create a wiki entry that could replace AlterEgo 213, demonstrating the 'correct' way to go about this. On Feb 23, 6:23 am, Jon Romero <darks...@gmail.com> wrote: > Thanks! That was what I was looking for! > The problem now is that is you try to run the unit test the way it is > described here (http://www.web2py.com/AlterEgo/default/show/213), I > get this error: > > > python web2py.py -S init -M -R applications/myapp/tests/default.py > > option -S not recognized > Usage: web2py.py [options] [test] [...] > > Options: > -h, --help Show this message > -v, --verbose Verbose output > -q, --quiet Minimal output > > Examples: > web2py.py - run default set of tests > web2py.py MyTestSuite - run suite 'MyTestSuite' > web2py.py MyTestCase.testSomething - run > MyTestCase.testSomething > web2py.py MyTestCase - run all 'test*' test > methods > in MyTestCase > > If I just put a prin "Hello world!" inside the test file, everything > works ok. So, I suppose that this file tries to load AGAIN the web2py > environment and there is > some sort of mix up? > > Any idea? > > On Feb 23, 3:23 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > python web2py.py --help > > > -S APPNAME, --shell=APPNAME > > run web2py in interactive shell or IPython (if > > installed) with specified appname > > -T TEST_PATH, --test=TEST_PATH > > run doctests in web2py environment; TEST_PATH like > > a/c/f (c,f optiona > > -R PYTHON_FILE, --run=PYTHON_FILE > > run PYTHON_FILE in web2py environment; should be > > used > > with --shell o > > -M, --import_models auto import model files; default is False; should be > > used with --shell option > > > python web2py.py -T <yourapp>/<controller>/<function> > > > It executes all doctests in environment. Have a look at sql.py for > > example doctesting with a database (using a sqlite database) > > > And if you want to use unittest > > > python web2py.py -S <yourapp> -M -R > > /path/to/web2py/applications/yourapp/tests/testControllerA.py > > > Will execute the file inside of the web2py environment (with access to > > database models as denoted by the -M option)' > > > Now since we had such a difficult time finding these options, please > > list links as to where the documentation on this subject can be > > updated and explained further. > > > -Thadeus > > > On Mon, Feb 22, 2010 at 5:21 PM, spiffytech <spiffyt...@gmail.com> wrote: > > > nside to doctests is they are harder to organize; you can't > > > cleanly separate different sorts of tests that all relate to the same > > > function (i.e., when a function is very sensitive to initial > > > conditions). With external unit tests each logically distinct test can > > > be represented with a distinct function, and that test can be run on > > > it's own, without the overhead of any other tests (unlike doctests, > > > where everything that tests a function must be run in order to test > > > the part you're interes -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.