devnettips

El otro día nos surgió un problema al realizar una aplicación Asp .Net MVC 3. Lo que necesitábamos era poder autorizar una aplicación en función de unos grupos que a priori no conocíamos, es decir, que queríamos poder configurar en el .config una serie de grupos que fueran los que tuvieran acceso a la aplicación. Esto nos llevó a tener que hacer una autorización personalizada en MVC. Veamos los pasos que tenemos que seguir para llevarla a cabo.

Para hacer esto nos apoyaremos en los action filters de MVC. Un action filter es un atributo que podemos aplicar a una acción de un controlador o a un controlador entero que modifica la manera en que la acción se ejecuta. En nuestro caso lo que haremos será crear un action filter personalizado para poder implementar la autorización personalizada que queremos.

Si nos vamos al global.asax vemos que hay una función llamada RegisterGlobalFilters en la que se está añadiendo el HandleErrorAttribute. Vamos a añadir nosotros aquí mismo un nuevo filtro llamado CustomAuthenticationAttribute:

Vamos a echarle un ojo a la clase CustomAuthenticationAttribute. Lo primero que vemos es que es una clase que deriva de AuthorizeAttribute, para poder así sobrescribir el comportamiento por defecto de la autorización. En el constructor, lo que estamos haciendo es cargar la lista de roles permitidos de nuestro web.config.

Después vemos que hacemos un override de tres métodos:

OnAuthorization
Este es el método que se llama cuando un proceso solicita autorización. En él, lo que haremos será mirar si la acción o el controlador está decorado con el atributo AllowAnonymous, hecho también por nosotros. Esto nos permitirá tener métodos accesibles para todo el mundo.

AuthorizeCore
Este es el método que realiza la autorización. Devuelve true si el acceso está permitido y false si no lo está. En nuestro caso, miraremos si el usuario que hace la petición es miembro de algún grupo de los definidos en el web.config. Aquí podríamos poner la lógica que fuera necesaria para cada caso en concreto.

HandleUnauthorizedRequest
Este es el método que se llama cuando una petición a una acción no ha sido autorizada. En nuestro caso haremos un redirect a un controlador que mostrará el mensaje de error.

Tal y como hemos comentado anteriormente, tenemos que hacer el atributo que nos permitirá tener un acceso anónimo a una acción:

Para finalizar modificamos el Web.config. En nuestro caso añadimos una entrada en el appSettings para indicar los roles que tienen permisos y configuramos la seguridad básica denegando el acceso a todo usuario que no esté autenticado.

Y con esto ya estamos. Espero que os haya servido.

Un saludo!

Hola a todos,

el próximo sábado 2 de Julio arranca catdotNet, el grupo de usuarios de .Net de Catalunya, con un evento inagural en en el Cybernàrium de Barcelona.

En este evento, a parte de la presentación del grupo que realizará Toni Recio contaremos con los siguientes ponentes:

• José Miguel Torres nos hablará sobre la gestión de dependencias con NuGet.
• Marçal Serrate nos hará una aproximación práctica a ASP.NET MVC 3.
• Álex Casquete nos hablará de las mejoras introducidas en la última versión de Entity Framework: Code First y DbContext.
• Marc Rubiño nos hará una aproximación práctica a JS y AJAX para programadores ASP .NET.

Podéis registraros para asistir en el evento aquí mismo.

Los que viváis cerca de Barcelona, no tenéis excusa para no ir!

Nos vemos el sábado!

Me encantan los Open Spaces. Mi primera experiéncia fue en Buenos Aires en marzo de 2009, y supuso una revolución para mi en la forma de encarar la organización de eventos. El segundo fue el del año pasado en Barcelona, en el que, a parte, participé en la organización. Y este fin de semana se realizó el Agile Open Spain 2011 en Pamplona, al que no podia faltar. Como siempre me encontré allí a un montón de amigos, aunque la novedad de este año fue poder ir acompañado de casi la totalidad de la gente de la oficina de Plain Concepts en Bilbao.

Una de las razones por las que me encantan los Open Spaces es porque creo que ejemplifican a la perfección el espiritu del agilismo. Es un evento hecho por la comunidad para la comunidad. Por supuesto que necesita un comité organizador ( y que lo hicieron a la perfección ) para todo el tema logístico, pero la «chicha» del evento, las 36 charlas que hubo, fueron un trabajo de los miembros de la comunidad para los miembros de la comunidad. Se formaron 36 equipos enfocados en dar el máximo valor posible a las charlas.

Yo propuse una charla sobre calidad del código que fue bien recibida y que creo que estubo bastante bien, aunque no se tocaron todos los temas que me hubieran gustado. La discusión se centró sobretodo en la cobertura de tests y en los comentarios en el código. También se habló de los equipos de QA.

Por otra parte asistí a charlas tan variopintas como Stubs, Mocks y Spies, taller práctico de histórias de usuario, talento, estimaciones, deduda técnica y romper la rutina. 

Por encima de las charlas en sí ( que podéis ver en detalle en los diferentes resúmenes hechos por los participantes ) yo me quedo con las personas que asistieron al evento. Se reunieron 150 personas preocupadas por su profesión, con ganas de mejorar su entorno, con ganas de hacer cosas para ellos y para los demás y comprometidos con la excelencia.

Espero ya con ganas el Agile Open Spain del año que viene, en el que espero veros a muchos de vosotros.

Un saludo! 

Puede darse el caso que tengamos un TFS 2010 instalado en inglés pero nos interese cargar una plantilla metodológica en castellano. Nuestro primer impulso será cargar la plantilla metodológica sin hacer ningún cambio en nuestro servidor y crear un proyecto con ella. A veces es bueno seguir los impulsos, así que vamos a ello.

En nuestro querido Visual Studio 2010 vamos al menú Team y abrimos el Process Template Manager:

Y seleccionamos nuestra plantilla para cargar. Se carga la plantilla correctamente y se nos añade a la lista de plantillas disponibles.

Una vez cargada la plantilla ya podemos crear un nuevo Team Project con ella, así que creamos un Team Project con el Team Explorer y como plantilla metodológica escogemos la plantilla recién subida. Todo parece ir bien hasta que…

 Le hechamos una ojeada al log y vemos que el error está en la creación del portal de Sharepoint ya que no encuentra un template del site para el idioma español (3082):

Para solucionar esto nos vamos a la web de Microsoft a descargarnos el Language Pack para nuestra versión de Sharepoint, en nuestro caso la 3.0. Y la instalamos, claro. Al finalizar la instalación nos pedirá si queremos ejecutar el asistente para configuración de Productos y Tecnologías de SharePoint.

 Le decimos que si y nos ejecutará el asistente, que prácticamente no requiere de nuestra intervención.

Y si todo ha ido bien:

Si nos vamos a la carpeta C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions12TEMPLATE1033XML (inglés) veremos que tiene un fichero ( WEBTEMP.Microsoft.TeamFoundation.SharePoint.Dashboards) que en la carpeta C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions12TEMPLATE3082XML (español) no está.

Tenemos que conseguir este archivo de alguna instalación del TFS en español y copiarlo aquí y volvemos a pasar el asistente para configuración de Productos y Tecnologías de SharePoint dejando las opciones marcadas por defecto. Una vez hecho esto ya podemos crear el nuevo proyecto con la plantilla metodológica en castellano.

Ahora solo nos faltará editar el portal de proyecto de SharePoint para que muestre los elementos en castellano en lugar de en inglés.

Espero que haya servido de ayuda.

Un saludo!

En el anterior artículo, veíamos como hacer un test funcional con CodedUI grabando nosotros los pasos del test. En el artículo de hoy veremos como codificar a mano estos pasos, ya que llega a ser más rápido y más flexible hacerlo así.

Empezaremos de la misma manera, creando un proyecto de test, añadiéndole un archivo de test con CodedUI y generando una nueva grabación. La diferencia es que ahora, en lugar de hacer clic sobre el botón de grabar y empezar a realizar los pasos, arrancaremos la aplicación y arrastraremos el botón con la cruceta de la barra del test builder sobre un control de la aplicación, en nuestro caso el textbox correspondiente a la operación.

 Al hacer esto se nos abrirá la misma pantalla que se nos abrió al hacer la aserción en el anterior tutorial. Esta vez, haremox clic sobre las dos flechas hacia la izquierda que hay arriba a la izquierda y se nos abrirá un panel que contiene un árbol donde se muestran los diferentes controles que vamos seleccionando.

 Seleccionaremos el control que acabamos de añadir y haremos clic sobre el botón de añadir el control al UI map. Haremos lo mismo con todos los controles, incluída la cruz de cerrar la aplicación, hasta que nos quede algo parecido a esto:

Ahora ya podemos hacer clic sobre el botón de generar el código de la grabación. El Visual Studio detectará que no hemos hecho ninguna grabación y nos preguntará si queremos que añada los controles seleccionados al UI map del test. Le diremos que si.

Si nos fiajmos en el test de donde hemos partido, veremos que no ha cambiado nada, ya que no se ha realizado ninguna grabación. Vamos ahora a hacer por código lo mismo que hacia Visual Studio automáticamente por nosotros antes. Para ello, no vamos a editar el archivo UIMap.Designer.cs, ya que este archivo es autogenerado y podriamos perder los cambios realizados allí. Para permitirnos añadir nosotros nuestros tests, Visual Studio nos proporciona una clase parcial vacia situada en el archivo UIMap.cs. Es aquí donde podemos hacer un método nuevo con las acciones que queremos que se realicen.

Empezaremos incluyendo la libreria de testing para los controles Wpf:

Lanzamos la aplicación a testear:

Definimos las variables para manejar los textbox de la calculadora, que en CodedUI son WpfEdit:

Ahora definimos las variables para manejar los botones:

 Inicializamos los textboxes con los valores que queremos testear:

Y simulamos un clic sobre los botones del igual y de cerrar la aplicación:

 Ahora simplemente tenemos que llamar a esta función desde nuestra clase de test, y veremos que si ejecutamos el test este hace todo lo que le hemos dicho y pasa correctamente.

Por ahora solo hemos comprobado que la aplicación no le pase nada raro, pero no hemos comprobado que el resultado sea el correcto. Para ello tenemos que simular nosotros lo que, cuando grababamos los tests, eran las aserciones.

Para ello vamos ha hacer algo parecido a lo que hace automáticamente Visual Studio. Nos vamos a crear una clase que contenga todos los parámetros que necesitamos ( los dos operandos, la operación  y el resultado de la operación) y vamos a crearnos una instancia pública de la misma en la clase UIMap.cs:

Modificaremos la función que acabamos de realizar en el UIMap.cs para que utilice los valores de las propiedades de esta clase y para que, después de clicar sobre el botón de igual, recupere el valor que hay en el textbox del resultado:

Ahora sólo nos queda rellenar los valores de los operandos y la operación desde nuestro test, y hacer un assert del valor esperado con el valor del parametro Resultado:

Y ahora sólo nos queda alimentar este tests con datos provenientes de un XML. Primero de todo nos creamos el XML, que tendrá una aspecto como este:

Ahora le decimos al test que sus datos se alimentaran de este XML. Para hacerlo, seguiremos los mismos pasos que si quisieramos hacer lo mismo en un test unitario. Nos vamos a la ventana de test view, seleccionamos el test y en la ventana de propiedades, clicamos sobre el botón situado en el campo Data Connection String. Se nos abrirá una pantalla como esta:

 Seleccionamos XML file y clicamos en siguiente.

Clicamos sobre siguiente:

Seleccionamos la tabla adecuada en el XML ( en nuestro caso sólo tenemos una ) y verificamos que los campos sean correctos. Clicamos en finalizar. Nos pedirá de copiar el archivo en el proyecto y de añadirlo a la lista de items a desplegar. Le decimos a todo que si.

Ahora ya estamos preparados para utilizar estos datos. Para hacerlo, nos ayudaremos de la propiedad DataRow del objeto testContextInstance, de la siguiente manera:

Y ya tenemos el CodedUI tests alimentado con datos de un XML!

Espero que el tutorial os haya gustado y no os haya aburrido en exceso.

Un saludo!

Como ya muchos sabéis, CodedUI es la tecnología de Microsoft que nos permite realizar tests funcionales sobre nuestra aplicación, sea esta del tipo que sea. En el artículo de hoy veremos como crear un test funcional básico y añadirle una aserción. Empecemos!!

Lo primero es presentaros la aplicación que vamos a testear. Se trata, como no, de una pequeña calculadora realizada en WPF y compuesta de 4 textboxes y un botón. En los tres primeros textboxes introduciremos los operandos y la operación a realizar y, al apretar el botón, se nos mostrará el resultado en el último textbox.

Para realizar los tests vamos a crear un acceso directo a la aplicación en nuestro escritorio y vamos a añadir un nuevo proyecto de test a la solución. A continuación, añadiremos un nuevo item al proyecto de test de tipo CodeUITest. Automáticamente se nos mostrará un cuadro de diálogo que nos da a elegir entre generar un nuevo grabando acciones o utilizar uno existente. Escogeremos la primera opción.

 Esto hace que nos aparezca la barra del CodedUI test builder, que es una pequeña barra que nos ayudará en nuestro cometido.

 Como podéis ver, la barra sólo tiene cuatro botones;

• Empezar o pausar la grabación.
• Ver los pasos que llevamos guardados.
• Seleccionar un control para hacer una aserción (luego lo vemos).
• Generar el código de la grabación existente.

Para empezar le daremos al botón de grabar y empezaremos a realizar la prueba que queremos guardar. En este caso, será hacer doble clic en el acceso directo, introducir una operación del tipo 5 + 6, darle al botón y cerrar la aplicación. Esto en nuestra clase de test genera un código tal como este:

Ahora veremos un poco más el código interno, pero por ahora nos vamos a limitar a ejecutar el test. Esto hará magia en nuestro ordenador y se nos abrirá la aplicación, se tecleará lo mismo que hemos tecleado nosotros, se pulsará el botón, se mostrará el resultado y se cerrará la aplicación. Ni Tamariz lo haría mejor!

Si miramos un poco el código interno, veremos que es prácticamente auto-explicativo:

Vemos como abre la aplicación, inserta los textos correspondientes y hace clic en los botones. Destacar sobre todo las tres líneas donde rellenamos los textboxes, porque lo utilizaremos después para alimenar al test de datos.

Ahora vamos a hacer una aserción sobre el textbox del resultado. Lo que queremos es que el test compruebe que la operación es correcta, no sólo que no hay ningún problema para ejecutarlo. Así pues, vamos a hacer un nuevo test como si fuera un test unitario, es decir, haciendo un método público decorado con el atributo [TestMethod]. En el cuerpo del método, hacemos clic con el botón derecho del ratón y seleccionamos la acción «Generato code for CodedUI test -> User CodedUI Test Builder»:

Volvemos a estar como antes, con la barra del CodedUI test builder. Realizaremos los mismos pasos pero, antes de cerrar la aplicación haremos clic sobre el botón de pausa y generaremos el códig de los pasos que llevamos hasta ahora. Ahora, haremos clic en el icono de la aserción y lo arrastraremos hasta el textbox del resultado. Esto hará que se nos habra la siguiente ventana:

Hacemos clic con el botón derecho en el campo text y seleccionamos la opción «Add asertion». Esto nos abre la siguiente pantalla, donde introducimos el valor que queremos asegurar que se muestre.

Generamos el código para la aserción, empezamos otra grabación para grabar el cierre de la aplicación y generamos el código para esta última acción. El código resultante tendria que ser algo parecido a esto:

Pasamos el test y vemos que se pone en verde. Si vamos a nuestra clase calculadora y cambiamos el comportamiento de la suma para que no devuelva la suma de los dos operandos, veremos que el test deja de pasar.

Bueno, pues por hoy ya es suficiente. Espero que os haya sido útil el tutorial. En la próxima entrega, veremos como alimentar este test de datos provenientes de un XML.

Después de que mi compañero Vicenç haya explicado sus experiencias en la XP 2011 me toca a mi el turno de hablar de los 3 días que pasé allí. La conferencia tuvo lugar en Madrid la semana pasada, y es la más grande de Europa y la segunda en tamaño del mundo después de la Agile Conferenceque se celebra en Estado Unidos, y yo tuve la inmensa suerte de asistir durante 3 días (la conferencia duraba 4, pero el primero de ellos no pude estar). Estaba realmente emocionado con la oportunidad ya que se iban a dar cita algunos de los grandes referentes en el mundo del desarrollo ágil de los últimos años cómo Mary y Tom Poppendieck creadores del término «Lean Software Development»,David Anderson creador de Kanban y muchos otros cómo J.B. Rainsberger, Jurgen Appelo, Michael Feathers…

Este jueves y viernes he tenido el placer de asistir a la XP Conference 2011 que se ha organizado en Madrid. Esta conferencia es la más importante de Europa sobre metodologías ágiles y la segunda del mundo después de la Agile Conference que este año se realizará en Salt Lake City.

El jueves, después del madrugón llegué puntual a las 9 de la mañana para estar en el stand de Microsoft y acabar de rematar los últimos flecos de la presentación que iba a hacer con Jose Luís Soria a las 12:35. Bueno, principalmente la presentación la hizo Jose Luís y yo le ayudé en una de las demos. Nuestra presentación versaba sobre integración continua y despliegue automatizado con Team Foundation Server y Visual Studio 2010. Justo antes, Jose Luís tubo otra charla, esta vez sobre el Definition Of Done, que fue muy divertida y un rotundo éxito y que os animo a ver.

La presentación nuestra estuvo también bien, pero no nos dio tiempo a hacer la demo de todo lo que queríamos. Teníamos planeada una build de integración continua, una gated check-in, una de despliegue de una base de datos y otra de un despliegue de una web personalizando la plantilla de proceso. Al final sólo nos dio tiempo a hacer la primera y la última.

Después de la comida vinieron las sesiones de la tarde. Yo fui a una mesa redonda sobre BDD que me gustó bastante, sobretodo porque hacía énfasis en algo que me parece esencial que es la comunicación con el cliente. El hecho de hacer BDD nos obliga a una fuerte comunicación con el cliente para definir las historias, una comunicación que tiene que ser de todo el equipo ( se comentó que estaría bien tener presen a alguien de negocio, a un tester y a un desarrollador como mínimo ).

Después fui a una session del Open Space sobre como migrar de un mal sistema de control de versiones a otro mejor. El chico que la propuso tenia dos servidores de CVS y tres de Subversion y se había decidido a cambiar a Git, entre otras cosas porque contaba con un equipo en China con muy mala conectividad para intentar mantener un sistema centralizado. Charlamos de los pros y contras de hacer una migración manteniendo el historial completo y de las ventajas e inconvenientes de los servidores distribuidos en función de los centralizados. Fue una charla muy interesante.

Para acabar el dia fui a una charla titulada “Forty years of software engineering, ten years of Agile, now what?.”. Esta no me gusto tanto. Básicamente se habló que no hay que quedarse con el estado actual del mundo ágil, sinó que se tendrían que potenciar más las comunidades locales y cambiar planes de estudio de las universidades, para que Scrum y otras no se queden solo como algo que está de moda y la gente aplica simplemente las liturgias, sinó que la gente entiende los principios y se guía en función de ellos. Después ya vino la cena y la fiesta, con Raquel Laina de guía por Madrid, pero de esto ya no os haré la crónica 😀

El viernes fui a dos sesiones. La primera era de “Refactoring in the 4th dimension” con Michael Feathers. Como ejercicio no estuvo mal ( practicamos ruby y pensamos un poco ) pero la charla no tubo nada de refactoring. En parte fue culpa nuestra por no mirar bien la descripción del workshop, pero por otra parte, si pones la palabra refactoring en un workshop, haz un poco de refactoring, que tampoco cuesta tanto.

Con un poco de mala leche por la elección de charlas hechas hasta ahora, decidí apostar a caballo ganador e ir a la charla de Jurgen Appelo sobre Agile Management. Era un tiro bastante seguro, pero cumplió mis expectativas. La charla estuvo muy bien y, a parte, hicimos tres ejercicios muy interesantes. El primero consistió en aplicar técnicas de delegación. Jurgen nos explicó que para él había siete niveles de autoridad, ordenados de más aseverativos a más colaborativos: Tell, Sell, Consult, Agree, Advise, Inquire y Delegate. Nos dio unas cartas con estos niveles y discutimos en grupo ( como si hiciéramos un planning poker ) sobre historias que nos habían sucedido o que nos inventábamos. Esto nos llevó a charlas muy interesantes y a profundidad en el nivel de confianza en la autoorganización que tenemos cada uno. Brian Marick tiene mucha confianza en la organización, porque votó a todo con un Delegate 😀

El segundo fue el ejercicio de los Meddlers. Nos dio unas casillas hexagonales que representaban cada uno de los actores en una organización: customer, cross functional team y functional team. A parte nos dio otras casillas con los roles de la gente: product manager, software developer, tester, line manager, etc. Y nos puso cuatro problemas, cuatro situaciones en las que teníamos que decidir como organizar el equipo. También fueron muy interesantes las discusiones a las que desencadenó.

Y finalmente llegamos a las métricas. Nos puso una parrilla con un eje que eran los múltiples stakeholders ( individual, team, organization, customer, supplier, shareholder y community ) y en el otro eje las dimensiones de las métricas ( time, tools, people, value, functionality, quality y process). Por equipos, tuvimos que pensar en métricas para cada una de las diferentes intersecciones de la parrilla, sin repetir ni fila ni columna, es decir, 7 métricas por equipo. Muy interesante también.

Y finalmente regaló un libro y también lo repartió de manera colaborativa. Cada equipo decidió que persona de su equipo se merecía más el libro, y después entre los seleccionados decidieron quien se lo quedaba.

Y esto es la XP2011 que viví yo. Como siempre, tan o más interesante que las charlas fue compartir charlas y momentos con gente tanto de la comunidad ágil española como de otros países.

Después de unas semanas liadas con el cambio de residencia y la incorporación a Plain Concepts volvemos a la carga con los artículos referentes a Moq ( aquí está el primero de la serie ).

Empecemos por el principio, es decir, por el constructor de nuestro mock. Al hacer el new tenemos dos opciones a la hora de indicar el comportamiento de nuestro objeto imitador:

• MockBehaviour.Loose: el mock devolverá siempre valores por defecto si no está definido el Returns y si se llama a una función del mock que no tenga un Setup, no lanzará ninguna excepción
• MockBehaviour.Strict: si se llama a una función del mock que no tenga un Setup, se lanzará una excepción y el test fallará.

Yo recomiendo utilizar la segunda opción ( MockBehaviour.Strict ) ya que seremos mucho más conscientes de lo que está haciendo el test.

En el anterior artículo vimos el uso de la función Verify. Esta función tiene 9 sobrecargas, en las que básicamente se pueden configurar dos cosas:

• El string de error en caso de no cumplirse la condición.
• El número de veces que queremos verificar que se ha hecho la llamada a la función.

Esta segunda opción se hace mediante la utilización de los métodos estáticos de la estructura Times. Ejemplos de utilización podrían ser:

• Times.Never(): queremos verificar que la función nunca se llama.
• Times.Once(): queremos verificar que la función sólo se llama una vez.
• Times.Exactly(3): queremos verificar que la función se llama tres veces.
• Times.Between(1, 5, Range.Inclusive): queremos verificar que la función se llama entre 1 y 5 veces, ambas incluidas.

En el anterior artículo también vimos como verificar que se había establecido el valor de una propiedad. Obviamente también podemos verificar que el valor de una propiedad se haya recuperado. Podemos verlo en el siguiente ejemplo:

[TestMethod]
public void Verify_Timeout_was_get()
{
    var mockDao = new Mock<IDAO>();
    AssetManager assetManager = new AssetManager(mockDao.Object);
    mockDao.VerifyGet(dao => dao.Timeout);
}

Siguiendo con las propiedades, también les podemos hacer un setup. La versión más sencilla es tratarlas como una función, de manera que podemos especificar el valor que queremos que devuelvan cuando se les hace un get. Para hacer esto, actuamos como si de una función se tratara:

mockDao.Setup(dao => dao.Timeout).Returns(1500);

La segunda versión es un poco más compleja, no en el código que tenemos que teclear ( muy sencillo ) sino en las funcionalidades que nos da. Si utilizamos el siguiente código:

mockDao.SetupProperty(dao => dao.Timeout);

estamos indicando a Moq que empiece a trackear la propiedad Timeout, con lo que el mock será consciente de cuando estemos intentando establecer un valor a Timeout y se guardará tal valor para futuros usos. Esto nos permitirá poder escribir un código tal como este:

[TestMethod]
public void Track_timeout_property()
{
    var mockDao = new Mock<IDAO>();
    mockDao.SetupProperty(dao => dao.Timeout);
            
    IDAO idao = mockDao.Object;
    idao.Timeout = 400;
    Assert.AreEqual(400, idao.Timeout);
}

Y esto es todo por por hoy. En futuros artículos veremos más características de este framework.

A testear!!

 PD: Añado aquí el código de este artículo y del anterior de la série. [View:/cfs-file.ashx/__key/CommunityServer.Components.PostAttachments/00.00.19.03.06/Moq.zip]