2012-05-02 18 views
5

Estoy empezando con RavenDB y me gusta hasta ahora. Sin embargo, estoy atascado en cómo debería probar las acciones del controlador de la unidad que interactúan con él.ASP.NET MVC, RavenDb y Pruebas unitarias

Todas las preguntas/artículos que he encontrado como este: Unit testing RavenDb queries dime que debería usar RavenDB en memoria en lugar de burlarlo pero no puedo encontrar un ejemplo sólido de cómo se hace esto.

Por ejemplo, tengo una acción de controlador para agregar un empleado de la base de datos (sí, es excesivamente simplificada pero no quieren complicar el asunto)

public class EmployeesController : Controller 
{ 

    IDocumentStore _documentStore; 
    private IDocumentSession _session; 

    public EmployeesController(IDocumentStore documentStore) 
    { 
    this._documentStore = documentStore; 

    } 

    protected override void OnActionExecuting(ActionExecutingContext filterContext) 
    { 
    _session = _documentStore.OpenSession("StaffDirectory"); 
    } 

    protected override void OnActionExecuted(ActionExecutedContext filterContext) 
    { 
     if (_session != null && filterContext.Exception == null) { 
     _session.SaveChanges(); 
     _session.Dispose(); 
    } 
    } 

    [HttpGet] 
    public ViewResult Create() 
    { 
    return View(); 
    } 

    [HttpPost] 
    public RedirectToRouteResult Create(Employee emp) 
    { 
    ValidateModel(emp); 
    _session.Store(emp); 
    return RedirectToAction("Index"); 
    } 

¿Cómo puedo comprobar lo que se añade a la base de datos en una prueba de unidad? ¿Alguien tiene algún ejemplo de pruebas unitarias que involucren a RavenDb en aplicaciones MVC?

Estoy usando MSTest si eso es importante, pero me complace probar y traducir las pruebas de otros marcos.

Gracias.

EDITAR

Ok, mi initialise prueba crea el almacén de documentos que se inyecta en el constructor del controlador, pero cuando corro mi prueba el evento OnActionExecuting no se ejecuta lo que no hay sesión de usar y la prueba falla con una excepción de referencia nula.

[TestClass] 
public class EmployeesControllerTests 
{ 
    IDocumentStore _store; 

    [TestInitialize] 
    public void InitialiseTest() 
    { 
    _store = new EmbeddableDocumentStore 
    { 
     RunInMemory = true 
    }; 
    _store.Initialize(); 
    } 

    [TestMethod] 
    public void CreateInsertsANewEmployeeIntoTheDocumentStore() 
    { 
    Employee newEmp = new Employee() { FirstName = "Test", Surname = "User" }; 

    var target = new EmployeesController(_store); 
    ControllerUtilities.SetUpControllerContext(target, "testUser", "Test User", null); 

    RedirectToRouteResult actual = target.Create(newEmp); 
    Assert.AreEqual("Index", actual.RouteName); 

    // verify employee was successfully added to the database. 
    } 
} 

¿Qué me falta? ¿Cómo puedo crear la sesión para usar en la prueba?

+0

He actualizado mi pregunta, véase más adelante –

Respuesta

7

Después de ejecutar la prueba unitaria, solo afirme que hay un nuevo documento en la base de datos y que tiene los campos correctos establecidos.

var newDoc = session.Load<T>(docId) 

o

var docs = session.Query<T>.Where(....).ToList(); 

RavenDB en memoria modo es allí para que usted no tiene que burlarse hacia fuera, que acaba de hacer lo siguiente:

  • Abrir en una nueva -memory embedded doc store (sin datos)
  • Si es necesario, inserte cualquier dato que necesite ejecutar su prueba de unidad
  • RUN th unidad de e prueba
  • mirada a los datos en el almacén en memoria y ver si se ha actualizado correctamente

actualización Si quieres una muestra completa, echar un vistazo a cómo el código RacoonBlog lo hace , este es el código que ejecuta Ayende's blog. Ver estos 2 archivos:

+0

Sí, estaba buscando un ejemplo más completo ya que he llegado tan lejos :) vea mi pregunta para obtener más información. – Nick

3

¿Cómo puedo comprobar lo que se añade a la base de datos en una prueba de unidad?

Usted no lo hace. No probamos tales cosas en pruebas unitarias. Esta es una responsabilidad de las pruebas de integración, NO de las pruebas unitarias.

Si desea unidades de clases de prueba, que dependen de alguna fuente externa (como su db), simule el acceso a la base de datos.

EDIT:

para corregir algunos errores mencionados, voy a citar la definición de MSDN (sin embargo todos los demás recursos de acuerdo con eso):

El objetivo principal de la unidad de pruebas es tomar la pieza más pequeña de software comprobable en la aplicación, aíslela del resto del código y determine si se comporta exactamente como espera.

Sin burlarse, se ignoran los principios básicos de la prueba unitaria: aislar y probar la pieza más pequeña posible.La prueba unitaria debe ser persistente, ignorante y no debe depender de una clase externa. ¿Qué pasa si el DB cambia con el tiempo? Reescribe todas las pruebas, aunque la funcionalidad se mantenga exactamente igual.

VENGA. Puedes darme -1 cuantas veces quieras, pero eso no te hará bien.

+2

eso es cierto, pero el modo en memoria de RavenDB hace que sea tan fácil de hacer pruebas de integración , que a menudo no necesita molestarse en hacer pruebas unitarias y burlarse de todo –

+1

@MattWarren, mmm, y pensé que estábamos escribiendo pruebas para ser persistente-ignorante ... Esta no es una pregunta acerca de si es fácil o no . La prueba unitaria NUNCA debe ir fuera de los límites de la clase, de lo contrario sería una prueba de integración. No importa si tiene su db en la memoria, en el archivo o en un servidor completamente diferente. El principio sigue siendo el mismo, me temo ... – walther

+0

Normalmente, con un RDBMS como SQL Server tendría un repositorio y me burlé de estas pruebas. Sin embargo, todos los artículos que he leído en RavenDB, incluido el blog de Ayende, dicen que no hacen eso ... así que pensé en intentarlo. – Nick

Cuestiones relacionadas