On 21 May 2007, at 19:27, Gary Bernhardt wrote: > On 5/21/07, Kevin Horton <[EMAIL PROTECTED]> wrote: >> I'm working on a small application that will respond to user input >> via the console. It is a very simple interface, with user input via >> "raw_input()", and the application produces result via "print" >> statements. I'm using python 2.5.1 on OS X, installed via Fink, but >> I'll also use the application with Movable Python 2.4.3 on Windows. >> >> I've got unit tests for many of the discrete units, but I still need >> to write some tests for the user interface, to help catch problems >> when refactoring code, etc. I've searched the web, but I can't find >> any description of how to write tests for such a user interface. Any >> advice would be appreciated. > > Two methods come to mind: > > 1. popen your program from the test and interact with it that way. > This is pretty easy with the subprocess module.
subprocess looks interesting. I played a bit in iPython, and managed to get a response from my program, so this might work. > 2. Modify your program to use a slightly more abstract IO interface. > This can be as simple as a class that has input() and output() > functions. Under normal conditions, it just passes the calls on to > 'raw_input' and 'print'. To test it, you can monkey patch the program > to use an alternative IO class that puts the test in control. Or if > you're feeling fancy, you can use dependency injection to achieve the > same effect. I'm a python newbie, so this approach looks a bit daunting at the moment. But, it might be a good way to learn a lot of useful stuff. > These are just off the top of my head, so there may be pitfalls. :) > I'd probably favor #2 because spawning processes can bloat your tests > up and slow them down. Then again, it sounds like you're looking for > a system test, not a unit test, so maybe spawning a process is the > right thing to do. Yes, I really am doing full system tests, so I want to simulate "real world" user interaction with my program as closely as possible. Speed is not a huge issue, within reason. > By the way, there's a pretty new testing-in-python list that's quite > good for this kind of question: > http://lists.idyll.org/listinfo/testing-in-python I had seen mention of this on someone's python blog, but had forgotten about it. Thanks for the reminder. I'll have a look at the list archives, and probably dare a newbie question. Thanks, Kevin Horton Ottawa, Canada _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig