Brendan Taylor wrote:
Hi list.I'm one of the XSF's GSoC 2007 students. I'm going to be implementing Encrypted Sessions (XEP-0116) and a test suite for it this summer. I've found a fair amount of information out there about test suites for servers. Unfortunately, there doesn't seem to be much about testing clients. So, client developers: what general architecture for a test suite would be most useful to you? It needs to work for any client interested in implementing the XEP, and I would like to make it as simple to use as possible. My current plan is to make a server component that will respond to several JIDs, each representing a different test case. Tests that require the suite to initiate a process will be initiated with a message sent to the suite. If you think it's worthwhile, logs of the raw XMPP traffic will be made available (via HTTP?). Your thoughts?
Is this part of your GSoC project or just a nice thing you want to do? :)First, I am not a client developer, so take what I say with a generous helping of salt.
It seems to me that part of the challenge with client testing is that clients interact with a broader range of entities than servers do. In many ways it's easier to test and write servers than it is to test and write clients. So for instance clients interact with:
1. Servers 2. Other clients 3. MUC services 4. Gateways 5. Pubsub services 6. Bots 7. Etc.So I suppose it depends on what you want to test. For your purposes, it may make sense to write a bot that interacts like a client would. But you could do the same thing as a server component, naturally, and that would enable you to create multiple JIDs and extend the testbed for testing features other than e2e. But then eventually your component will essentially do everything, simply in test mode. And that seems like a big project. :)
Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
