Good integration tests are hard. There are lots of approaches for testing server and client libraries all with various tradeoffs and problems that come up. Some are obvious, some are a little more tricky.
I'll run through some approaches I've come across developing server APIs along with their corresponding clients, while developing these in a highly distributed systems setup at Engine Yard.
I set this up with a story about a music label company exposing an API for musicians to consume, and how to build a good robust client library with different paradigms.
I have working tested examples of each approach, to play with, after the talk.
I've given this talk at a few places and will present this at RailsConf next week as well. I've gotten pretty good feedback. However, I'd be even more happy to hear and learn more from you! My talk is already up, here:
Let me know if you need any other info!
Totally agree with @Fotos. Your identity will be revealed on the next phase anyway :)
Writing (good) integration tests is a difficult endeavour and one that many engineers avoid mostly due to the huge development effort and high cost maintenance. I think lots of people would love to see a new approach in integration testing especially one that stems for experience.
As a side note, I believe you should not disclose identifiable information about yourself. At this point of the CFP process what matters is the content and not the author. Thus you should avoid mentioning your name or other conferences where you have given this talk. It would be kind to remove such sections and instead elaborate more on the content. You can read more about the CFP in the FAQ and especially the How anonymous does my proposal have to be? question. For example instead of linking to your presentation you could extract the relevant / intriguing parts and highlight them here and this way gather more comments and valuable feedback. ;-)