Pruebas unitarias sobre servicios WCF

Estoy poniendo manos a la obra para aumentar mis habilidades. Realmente he realizado pruebas de funcionamiento a la vieja usanza pero llega el punto donde uno siente que su desarrollo va lento, entonces te das a la tarea de buscar otras opciones, herramientas y técnicas que te permitan agilizar.

El proyecto donde participo es complejo, requiere de un gran equipo. Los bugs son el pan de cada día, junto con nuevos requerimientos, derivados en buena parte del ciclo de desarrollo actual. Por ello es que busco nuevas técnicas. El objetivo muchas veces es similar (metafóricamente) a desarmar una bomba: mueves mal un cable y "BUM", hay un tiempo de compromiso y las cosas se van juntando, entonces no hay mucho tiempo para prueba-error.

¿Qué hago entonces? Analizo... analizo... analizo... sigo flujo de datos, pregunto, pienso... Y no tiro una solo línea de código hasta estar seguro de dónde está el problema: Base de datos, servicio, controlador, front-end (con sus múltiples estructuras), reporte. Hasta el final y corroborando comportamiento, para el caso de bugs, es que escribo unas cuantas líneas, no muchas, solo las necesarias.

Pero para desarrollos nuevos es diferente la situación, y retomando un consejo de nuestro líder técnico...

Pruebas Unitarias sobre Servicios WCF.

La estructura que recomiendo usar para un método de servicio WCF es:

• REQUEST y RESPONSE propios del método, cada uno con unas propiedades que nos permitan controlar posibles errores: Numero de error (definido por el Framework o propio), Mensaje de error (igual), Bandera que indica presencia de error.
• Objeto contenedor de datos: una clase que contiene como propiedades todos los datos que podemos requerir enviar/recibir en nuestro método del servicio.

¿Por qué así? Porque con eso evitamos modificar drásticamente los métodos cada vez que requiramos cambiar estructuras. Estamos encapsulando.

Dentro del método es conveniente manejar un try-catch-finally para atrapar y manejar posibles errores o lanzar excepciones según necesitemos, y de esta forma devolver correctamente una respuesta que podamos manejar.

//... en el archivo .cs de mi clase...
public class Contacto {
  public string Nombre {get; set;}
  public string Teléfono {get; set;}

  public Contacto(string nombre, string telefono) {
    Nombre = nombre; Telefono = telefono;
  }
}

//... en el archivo .cs que define mi REQUEST y RESPONSE para mi servicio...
[DataContract]
public class ContactoRequest {
  [DataMember]
  public Contacto ElContacto {get; set;}
  [DataMember]
  public int ErrNo {get; set;}
  [DataMember]
  public string ErrorMsg {get; set;}
  [DataMember]
  public bool tieneError {get; set;}
}

[DataContract]
public class ContactoResponse {
  [DataMember]
  public string EnCadena {get; set;}
  [DataMember]
  public int ErrNo {get; set;}
  [DataMember]
  public string ErrorMsg {get; set;}
  [DataMember]
  public bool tieneError {get; set;}
}

//... en el archivo .cs del servicio...
public class MiServicio {
  public ContactoResponse ACadena(ContactoRequest request) {
    ContactoResponse response = new ContactoResponse() {
      En_Cadena = request.Contacto.Nombre + "::" + request.Contacto.Telefono
    };
    return response;
  }
}

Ahora, en el IDE VStudio, sobre el método en cuestión damos clic con el botón secundario del mouse y elegimos "Crear pruebas unitarias", nos abre un cuadro de dialogo al que solo le damos al inicio "Aceptar" para que genere la prueba. Si dentro del método de la prueba generó un código, podemos borrarlo sin problemas.

Ahora (nuevamente), generamos el código necesario para llamar al servicio (supongamos un servicio con métodos que no requieren conexión a base de datos, para mayor facilidad), su REQUEST y la instancia del servicio. Invocamos al método y el resultado lo asignamos a una instancia del RESPONSE.

Hasta aquí todo bien y bonito. Pero con lo que sigue la cosa se pone mejor...

Disponemos de una clase Assert que tiene los métodos: IsTrue e IsFalse que reciben una condición de verdad y un mensaje. Si la condición se cumple, de acuerdo con IsTrue o IsFalse, la prueba es satisfactoria, en caso contrario, la prueba no cumple, se dispara una excepción y se regresa el mensaje especificado. Assert tiene otras funciones similares de acuerdo a lo que se desee evaluar.

De acuerdo con las lecturas que he realizado,se recomienda crear una nueva prueba por cada caso que se quiera validar y no modificar la prueba ya aprobada.

Sus comentarios, sugerencias y opiniones ayudan a enriquecer mis publicaciones para que sean más útiles a más desarrolladores. Agradezco la colaboración.