I don't know why I was so stuck on the idea of *actually* using the XML-RPC interface to test the functionality exposed by XML-RPC, when I can just call all of the methods directly.
Unless something in xmlrpclib or SimpleXMLRPCServer breaks (which isn't something I can do much about), you end up with the same results. I can't believe I wasted this much time on the problem!!!
sugarbot's aim is to provide testing and automation facilities for the OLPC Project's Sugar GUI. The project must first identify and evaluate possible implementation options, and then implement the best choice. Although it has a Sugar focus, sugarbot should be easily extensible to other Python-based GUI's.
Wednesday, July 2, 2008
Subscribe to:
Post Comments (Atom)
Blog Archive
-
▼
2008
(91)
-
▼
July
(27)
- Crunchtime
- Trying to keep it pretty...
- It's Alive!!!
- Mutliple Clients, Return Status
- Multiple Clients
- Big Changes
- Inheritance
- Somebody please tell me why the following code doe...
- So Close!
- Missing Something
- Sugarbot Diagram
- Stateful XML-RPC Server
- Full automation
- Automated Launching: Go!
- Launching Activities Automatically
- Mid-Summer Screencast
- WTFBBQ
- ScreenFlick
- O ya
- Wierd logging issue...
- Woot?
- Buildbot is [almost] working
- Buildbot Up and Running
- Ideas??? Buildbot complains...
- Next Step
- Feels good
- More difficult than it needed to be...
-
▼
July
(27)
1 comment:
Well, sort of. Sure, XML-RPC probably won't break, but you really want to test the interface between your code and the XML-RPC protocol. In particular, do your XML-RPC functions return things that can be serialized over XML-RPC? With this approach you would not know from your tests.
Post a Comment