Pregunta

Mi aplicación

Tengo un diseño de aplicación que es similar al siguiente:

  • Web capa de aplicación - asp.net MVC aplicación con controladores y vistas que POCOs de uso y los servicios de llamadas
  • Servicio de capa - procesos de negocio que POCOs uso y los registros de llamadas
  • capa de datos - repositorios que uso POCOs y se comunican con el modelo en forma de modelo de EF que es parte de esta misma capa
  • capa POCO - define todas las clases que se utilizan para inter comunicación entre estas capas

Así que mi capa de datos es completamente transparente para la implementación del modelo de datos porque la capa superior no utilizan las entidades de datos en absoluto.

Prueba

Por mucho que entiendo unidad, la integración y las pruebas del sistema (con relación a Asp.net MVC) es la siguiente:

  • pruebas unitarias - éste es fácil. Mock desacoplado objetos e inyectarlos en su unidad de prueba de modo unidad probada usará
  • pruebas de integración - debe hacer un grupo de unidades de producción de funcionalidad y se burlan de los demás: por lo que escriben pruebas de integración que la prueba del controlador, el servicio y la integración repositorio sin utilizar realmente la base de datos de producción
  • pruebas del sistema - las pruebas realizadas en todas las capas sin ningún tipo de burla, lo que significa que tengo que la producción de su uso (prueba) de base de datos, así

Problema

Puedo ver fácilmente cómo escribir pruebas unitarias, así como las pruebas del sistema, pero no sé cómo escribir pruebas de integración? Tal vez mi punto de vista de ellos está completamente distorsionada y no entiendo en absoluto.

¿Cómo debería de integración y pruebas del sistema una escritura para una aplicación Asp.net MVC?
O cualquier aplicación .NET para el caso?

Algunos código que ayuda a explicar el problema

Supongamos que tengo clases como:

  • llamadas TaskController en TaskService
  • llamadas TaskService en TaskRepository
  • TaskRepository manipular datos EF internamente

Así que aquí están mis (abreviadas) clases:

public class TaskController
{
    private ITaskService service;

    // injection constructor
    public TaskController(ITaskService service)
    {
        this.service = service;
    }

    // default constructor
    public TaskController() : this(new TaskService()) {}

    public ActionResult GetTasks()
    {
        return View(this.service.GetTasks());
    }
    ...
}

public class TaskService : ITaskService
{
    private ITaskRepository repository;

    // injection constructor
    public TaskService(ITaskRepository repository)
    {
        this.repository = repository;
    }

    // default constructor
    public TaskService() : this(new TaskRepository()) {}

    public IList<Task> GetTasks()
    {
        return this.repository.GetTasks();
    }
    ...
}

public class TaskRepository : ITaskRepository
{
    public IList<Task> GetTasks()
    {
        // code that gets tasks from EF and converts to Task POCOs
    }
    ...
}

Unidad de prueba es simple y se vería así:

public void UnitTest()
{
    var mock = new Mock<ITaskService>();
    // other code that mocks the service

    TaskController controller = new TaskController(mock.Object);

    // do the test
}

Sin embargo, cuando se trata de una prueba de integración, ¿cómo puedo burlan sólo algunas partes de la integración.

public void IntegrationTest()
{
    // no mocking at all
    TaskController = new TaskController();
    // do some testing
}

En primer lugar, no puedo simplemente la base de datos simulada aquí? Podía burlarse repositorio y tienen un servicio real y el controlador aunque ...

¿Fue útil?

Solución

Pruebas de integración debe probar la integración entre los componentes. Mientras que las pruebas unidad de prueba piezas individuales de un solo componente, integración prueba las interacciones entre los componentes, y están destinados a trabajar en vivo. Así que una prueba de integración sería utilizar una base de datos y cualquier otro dependencias externas, en su mejor momento para burlarse de estos servicios en la unidad de pruebas.

La prueba del sistema para mí sería ensayos de funcionamiento (otro nivel de prueba usando algo como ajuste), o ui prueba a través de una herramienta como herramienta de control de calidad o TestComplete de telerik.

HTH.

Otros consejos

Las pruebas de integración que no implican la interfaz de usuario puede todavía ser escrito en NUnit, xUnit, etc.

Para ASP.NET MVC en particular (o cualquier aplicación web), puede utilizar WatiN o selenio al sistema de escritura / pruebas de integración utilizando la interfaz de usuario.

También puede ser que desee mirar a TST para las pruebas unitarias de T-SQL, y SpecFlow si eres curioso acerca de BDD en .NET.

Nota: Escribí esto antes de la pregunta se ha actualizado con código y una descripción de la situación específica. En realidad, no aborda la cuestión más, pero espero que todavía será interesante / útil a alguien.

Yo sólo respondió a una pregunta relacionada: Integración pone a prueba la aplicación . Creo que abordó la cuestión aquí, mediante la presentación de un enfoque claro para tomar.

Parte del problema es que las pruebas de integración de nivel superior obtienen v demasiado complejo. Rápidamente. Es la naturaleza del problema, por lo que prefiero para asegurarse de que todas las piezas separadas de trabajo como se pretende, a través de pruebas unitarias y pruebas de integración se centró en función de la clase en cuestión.

Con lo anterior en su lugar, sólo tiene que asegurarse de que las piezas separadas están enganchados correctamente, así que utilizar las pruebas del sistema completo para eso. Esto tiene el mejor de su efecto si el código sigue duras y áridos.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top