¿Cuál es el marco de burla elegido en Unit Test Library para Windows Store Applications?

Question

Cuando escribo pruebas de unidades, me gusta usar Rhino Mocks.

Así que cuando comencé mi primera aplicación de Windows Store, naturalmente comencé primero con mis pruebas unitarias. Cuando traté de añadir RhinoMocks través NuGet He recibido el siguiente error

No se pudo instalar el paquete 'RhinoMocks 3.6.1'. Está intentando instalar este paquete en un proyecto que se dirige a '.NETCore, Versión = v4.5', pero el paquete no contiene ninguna referencia de ensamblaje que sea compatible con ese marco. Para obtener más información sobre , comuníquese con el autor del paquete.

Tuve el mismo problema con Moq.

¿Existe un marco de burla para .NETCor, Version = v4.5?

Answer 1

La mayoría de los marcos de burla se basan en Reflection.Emit. Desafortunadamente Reflection.Emit no está en WinRT. Esto significa que no puede hacer proxies dinámicos. (Es decir, burla en tiempo de ejecución). Esto deja pregeneración de simulaciones que se referencian en tiempo de compilación. El único marco que conozco es una rama experimental de Moq: https://github.com/mbrit/moqrt

Answer 2

Aquí están mis sugerencias, tenga en cuenta que aún no he probado ninguno de estos. Here es un enlace a un artículo sobre las dos primeras opciones.

1. Typemock aislador - caro, pero parece que sería hacer el trabajo
2. Microsoft falsificaciones (evolucionado a partir de un proyecto en el MSR llamada Moles)
3. En lugar de burlarse (o hacer la inyección de dependencia), se puede usar una técnica diferente. Podría usar inyección parametrizada y simplemente pasar la información que necesita probar. Esto reduce a objetos grandes a delegados y primitivos, aliviando la necesidad de un marco de burla. Here es más sobre esto, incluyendo un example de la técnica en acción.

Answer 3

En realidad, Philipp Dolder, uno de los colaboradores de FakeItEasy ha llegado con un enfoque interesante y trabajando sobre la base de bibliotecas de clases portátiles. http://www.planetgeek.ch/2013/02/01/fakeiteasy-and-windows-store-apps-are-becoming-friends/

En esencia, se propone la siguiente solución:

1. colocar todo el código productiva que será TDD-ed en una biblioteca de clases PCL donde se selecciona cualquiera que sea marcos de destino que desea apoyar
2. Cree su ensamblaje de prueba como una biblioteca de clases normal
3. Agregue las referencias a FakeItEasy y sus marcos de prueba de elección (por ejemplo, NUnit + FluentAssertions) a su *.Equipo de prueba
4. Sólo coloque el material de interfaz de usuario que no se puede probar en un proyecto de Windows App Store

Answer 4

Hice esto para su uso con Windows Phone 7, debería funcionar con Windows 8, ya que es sólo un paso posterior a la acumulación :

http://dontcodetired.com/blog/post/Introducing-%28probably%29-The-Worlds-Only-Mocking-Framework-for-Windows-Phone-7-%28WP7%29.aspx

Answer 5

sé la pregunta original es viejo, pero hay muchos de nosotros todavía por ahí tratando de lograr burla en Windows tienda de aplicaciones.

Recientemente he comenzado a usar MoqaLate que dice: Burlarse de Windows Phone & Windows Store aplicaciones. En realidad, crea físicamente las MockingClasses después de generar su solución. Entonces, después de la compilación, tendrá una carpeta con alguna implementación simulada de sus clases.

Creo que no es la mejor opción. La burla en tiempo de ejecución será lo ideal, pero mientras tanto crea los burlas para mí.