На самом деле разрабатывать под WinPhone достаточно удобно. Я с .NET-ным опытом начал писать боевой код буквально за пару недель, при том что с Silverlight раньше не работал вообще. Другое дело что в самой системе ограничения есть, но с этим сталкиваешься только потом.
И это не такой уж геморрой. Под Android например «родными» средствами покрытие вроде вообще никак не контролируется, а тесты запускаются только на эмуляторе или девайсе, что жутко неудобно. Под iOS тоже «специфика» какая-то есть. Вообще в мире мобильной разработки ещё идёт становление средств и подходов, как было лет 10-15 назад с серверной и десктопной разработкой. ИМХО конечно :)
Кстати, вот сейчас задумался. А в чём проблема покрытия заключается? Эмм… я, что, собственно, имею ввиду. Не могу понять почему я не могу писать тесты как обычно и смотреть покрытие утилитой dotCover? Всё, что нужно — замокать, в независимости от того, Runtime ли это проект, или проект библиотеки. В чём проблема-то? В чём отличие от разработки под десктоп с точки зрения написания тестов?
В Windows Phone используется другой рантайм, не десктопный .NET, а Silverlight. Для него нет (по крайней мере совсем недавно не было) средств контроля покрытия. Привычные средства (dotCover тот же) не умеют работать с Silverlight-овскими сборками. Поэтому и танцы.
Да, думал о Moq, но потом решил от него отказаться. Когда тесты выросли из модульных до функциональных, то с помощью Moq тяжело было бы достоверно эмулировать те же файлы или ответы сервера. Да и для образовательных целей лучше «хардкорд» :)
Но вообще Вы верно подметили, с правильными моками в тестах у меня почему-то не склеивается.
Контроль покрытия кода при unit-тестировании в Windows Phone