¿Cómo puedo realizar una prueba unitaria de mi servicio web REST?

13

Soy nuevo en las pruebas unitarias, tengo un método web REST que simplemente llama a DB y llena un DTO. El pseudo código es

public object GetCustomer(int id)
{
  CustomerDTO objCust = //get from DB
  return objCust;
}

Mi duda es cómo escribir pruebas para estos métodos y el tipo de pruebas (Integración / Unidad) que se incluirán. Y para pruebas unitarias, ¿tiene que golpear el DB. Si lo fuera y pasara un ID de cliente y hiciera pocas afirmaciones, los datos podrían cambiar eventualmente resultando en fallas.

Creo que me estoy perdiendo algo al entender estos conceptos.

    
pregunta Sunny 26.03.2013 - 15:26

1 respuesta

16

Mientras se realizan las pruebas unitarias, no se espera que realicen pruebas con una base de datos, o al menos no con una base de datos que no haya preparado para las pruebas unitarias. Probar con una base de datos, y como tal, probar diferentes capas de su aplicación al mismo tiempo generalmente se considera como pruebas de integración . Con las pruebas unitarias, se supone que debe probar solo lo que hace su método, lo que devuelve según los diferentes parámetros y cuándo (o no) debería fallar.

Es muy esperado que en tu método hagas llamadas a métodos X de otras clases. No estás probando estos métodos X , por lo que lo que debes hacer es simulacro estos métodos.

Supongo que estás escribiendo tu código en Java, en ese caso tienes grandes marcos burlones como Mockito lo que puede ser útil para usted. Ya sea que uses o no un marco burlón, solo te diré que te ahorrarán mucho tiempo y el que mencioné al menos no es realmente complicado.

Si solo desea escribir su propio simulacro para experimentar, suponga que tiene la siguiente clase CustomerRepository :

public class CustomerRepository {
 public CustomerDTO getCustomer(int id) {
   ...
 }
}

Puedes escribir tu propia clase CustomerRepository simulada y sucia de la siguiente manera:

public class MockedCustomerRepository extends CustomerRepository {
 public boolean bThrowDatabaseException;
 public boolean bReturnNull;
 public boolean bReturnCustomerWrongId;
 public boolean bReturnCustomerWithId;
 public CustomerDTO getCustomer(int id) {
  if(bThrowDatabaseException) { 
    throw new DatabaseException("xxx"); 
  } else if(bReturnNull) { 
    return null; 
  } else if(bReturnCustomerWrongId) { 
    throw new CustomerNotExistException(id);
  } else if(bReturnCustomerWithId) { 
    return new CustomerDTO(id); 
  }
 }
}

Luego, en su caso de prueba, básicamente reemplaza su instancia "estándar" de CustomerRepository con una instancia simulada que le permitirá probar su método para varios resultados de getCustomer :

public class CustomerRestTest {
  public void testGetCustomer_databaseFailure() {
    MockedCustomerRepository dto = new MockedCustomerRepository();
    dto.bThrowDataBaseException = true;
    yRestClass rest = new MyRestClass();
    rest.dto = dto;
    rest.getCustomer(0);
    // depending on what you do in your getCustomer method, you should check if you catched the exception, or let it pass, etc.. Make your assertions here

  public void testGetCustomer_customerNotExist() {
    // etc.
  }
}

En general, cada método de prueba debe probar solo una cosa, esto ayuda a mantener las pruebas pequeñas y enfocadas en una tarea.

Voy a repetirlo :-) Escribir una clase simulada completa toma algo de tiempo como ves. Considere el uso de un marco de burla, cuanto menos se escribe un código, menos errores se cometen , ¿verdad? La burla de un método que lanza una excepción, o devuelve un valor dado para un parámetro dado es pan comido y toma 2 o 3 líneas (al menos con mockito)

Espero que ayude a probar tu método REST.

    
respondido por el Jalayn 26.03.2013 - 16:08

Lea otras preguntas en las etiquetas