Mostrando las entradas con la etiqueta Testing. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Testing. Mostrar todas las entradas

miércoles, 11 de noviembre de 2009

System.TypeLoadException: Could not load type al hacer Unit Test a una solución de SharePoint

Síntoma:

Al hacer una prueba unitaria tan sencilla como instanciar en memoria una clase despliega el error mencionado en el artículo.  Los demás test si funcionan pero este nuevo no.

Código de prueba con NUnit:

[TestFixture]
   public class TestFamiliarRepositorio
   {
       [Test]
       public void Test1()
       {
           var x = new DummyRepositorio();
           Assert.IsNotNull(x);
       }
   }

Escenario:

Software Instalado:

  • Visual Studio 2008 SP1
  • WSPBuilder
  • Resharper 4.5
  • Windows Server 2003 con SP2

Tipos de Proyectos en la Solución:

  • 2 Class Library (Dominio, Repositorio)
  • WebPart Project (Plantilla WSPBuilder)
  • Test Library (Pruebas unitarios del Repositorio)

Después de una refactorización con Resharper al crear este nuevo test para un nuevo Repositorio me mostró el error:

System.TypeLoadException: Could not load type

Que hice para que no lo haga usted que de todos modos no me funcionó:

Desinstalar Resharper, Instalar NUnit 2.5.2 y correr el test allí que me dio el mismo error. Reinicié el Visual Studio 2008 incontables veces y la máquina virtual donde estaba instalado.

Solución final:

El proyecto Web Part requiere que los ensamblados asociados al Web Part estén firmamos con una llave al parecer en una de las refactorizaciones se daño.  Lo que hice fue eliminar las firmas de los DLL y ejecutar los test y todo funcionó bien.  Luego agregar nuevas llaves y dejar los DLL´s firmados y con ello todo volvió a la normalidad (En propiedades del proyecto). 

image

Recuerdo que ya una vez tuve el mismo problema y me decidí cambiar de las Visual Studio Extension Tools for SharePoint v 1.2. para WSPBuilder entre otras cosas así que creo que esto hubiese corregido también el problema que en aquel entonces me dio.  Igual estoy muy contento con WSPBuilder y no haré el cambio por lo menos  no hasta VS 2010 que ya están integradas las VSe dentro del IDE, y que ya trae todas las funcionalidades que hacen atractivo WSPBuilder pero amigo lector si le da el error:

System.TypeLoadException: Could not load type

 

Favor revise los ensamblados firmados que pienso muy seguramente le resolverán el problema.

Código de Prueba que al final corrió con el Framework de testing integrado de VS 2008:

[TestMethod]
public void TestMethod_ObtenerListadoPorCodigoEmpleado_FamiliarRepositorio_InstanciaColleccionEsperado()
{
    IFamiliarRepositorio familiarRepo = new FamiliarRepositorio("nombreConexion");
    const int codigoEmpleadoPrueba = 1;
    var listadoEsperado = familiarRepo.ObtenerListadoPorCodigoEmpleado(codigoEmpleadoPrueba);
    Assert.IsNotNull(listadoEsperado);
}

Code4Fun!,

Manolo Herrera

martes, 16 de septiembre de 2008

Desarrollo Basado en el Comportamiento o BDD

Creo que los principios orientados a Objetos o mas conocido como OOP han encontrado eco a lo largo de los años, y disciplinas recientes han enfatizado la importancia de los mismos, en otras palabras la madurez de esta teoría hoy en día se ve mas cercana a la práctica y el uso generalizado de estas herramientas permitirán que llegemos a dicha madurez.

El Desarrollo Basado en el Comportamiento o Behaivor Driven Design, desafía a los desarrolladores a cuestionar cuales son las responsabilidades que ellos asigna a sus clases son apropiadas o pueden delegarse o moverse a otra clase. Cuestionarse de esta forma y utilizar Mocks para llenar los roles requeridos de colaboración de las clases, promueve el uso de interfaces basadas en roles, y esto también ayuda a mantener las clases pequeñas y desacopladas.

Al igual que el Diseño Basado en Dominio este describe el propósito y beneficio de su código.

Permite a los desarrolladores concentrarse en por qué el código debería de ser creado, en vez de los detalles técnicos, y minimiza la traducción entre el lenguaje en el cual se escribe y el lenguaje hablado por los usuarios.

(Extracto de WikiPedia)

Al final el Desarrollo Basado en Comportamiento no es mas que la evolución del Desarrollo Orientado a Pruebas o TDD. Veamos esta evolución en pasos, de como el aprendizaje y la adopción de TDD a llevado a su evolución y a convertirse en BDD:

  1. El desarrollador inicia escribiendo Pruebas Unitarias de su código con frameworks de prueba como NUnit.
  2. Cuando el conjunto de pruebas se incremente el desarrolladores disfruta y aumenta su sentido de confianza en el trabajo que realiza.
  3. Como consecuencia el escribir pruebas antes de escribir el código ayuda al desarrollador a concentrarse en escribir solamente el código que necesita.
  4. Así mismo, el desarrollador utiliza las pruebas como una forma de documentación para el código que no ha visto por algún tiempo.
  5. Llega el momento que el desarrollador se da cuenta que escribir pruebas en esta forma ayuda a descubrir la interfase de la aplicación de su código y TDD llega a ser parte del proceso de Diseño.
  6. Los expertos en TDD señalan que los desarrolladores se dan cuenta que TDD es acerca de definir el comportamiento en vez de las pruebas.
  7. El Comportamiento es acerca de las iteraciones entre los componentes del sistema y el uso de Mocking es fundamental para el avance de TDD.

(Extracto del sitio BDD.org )

La motivación es que iniciemos el camino al desarrollo basado en pruebas y evolucionemos al basado a comportamiento y mejor aún podamos desarrollar el modelo basado en dominio.

Hasta una próxima amigos!,

Manolo Herrera