Although the DuckTyping approach looks interesting, it still leaves it to the developer to hand-write all the interfaces. Moreover, when doing so, any typo will compile and lead to exceptions at runtime. I fully agree with Juho that unit testing of applications based on the Runtime SDK for .NET is currently very cumbersome. It is obvious that design goals for testability didn't play a part when the Runtime SDK was developed. The result is a lack of seams where original classes can be replaced with stubs: The SDK does not define interfaces, and most of the classes are sealed and/or have non-public constructors. If at least classes were not sealed, it would be possible to create stubs for them with common isolation or mocking frameworks such as Moq, FakeItEasy or NSubstitute.
I also would like to see a sample project of unit tests for the API. How do you isolate the class under test from its dependencies? How do you create stubs for parameters that you pass to the tested method, if that parameter is of a sealed type with no public constructor?