Mocking: El comienzo

0 comentarios

Hace cuestión de un par de meses preparé un pequeño texto para dar una escueta charla alrededor del concepto de mock y técnicas básicas de mocking, la idea era que un equipo de programadores tuviera un primer contacto para la creación de tests unitarios donde el codigo a probar tiene una dependencia con clases externas.

Claramente hay montones de artículos, textos, papers, tutoriales, ... en internet que cuentan el mismo problema que estamos tratando en este artículo, sin embargo, puede ser que siempre le pueda servir de ayuda a aquellos programadores que van a enfrentarse con el mismo tipo de problema, y otro ejemplo más siempre ayuda a comprender mejor cómo aplicar la solución.

Cuando como programadores nos enfrentamos por primera vez a la creación de tests unitarios para el código que estamos programando, uno de los problemas complicados es el de comprender cómo crear tests unitarios para aquellas clases que tienen dependencias con clases externas, ya que una de las primeras ideas que se nos ocurren es, la de probar conjuntamente la o las clases dependientes, a la vez que la clase que inicialmente teníamos en mente. Esto contradice la definición de test unitario, donde se pretende crear tests para una única unidad, en este caso hablamos de una clase sin tener que probar el codigo de clases dependientes. Si la clase sobre la que estamos trabajando y creando los tests unitarios depende de otras clases, por definicion sabemos el comportamiento de las clases dependientes, sabemos de antemano, por la definicion o especificacion dedicha clase la salida para una determinada entrada en cada uno de sus metodos que la componen.


Tomando como ejemplo de lo comentado el esquema anterior, nuestra idea es crear tests unitarios para la clase Navigator, la cual hace uso internamente de NavigatorFlow y NavigatorListener. Dado que inicialmente no hemos creado interfaz para NavigatorFlow (INavigatorFlow), la clase Navigator hace uso directo de NavigatorFlow, lo que obliga que al ejecutar los tests que escribimos de Navigator se ejecute el codigo de NavigatorFlow, lo que ademas de agregar complejidad a los tests unitario, estamos probando dos unidades en lugar de una.

Para evitar esta complejidad y hacer nuestras vidas mas fáciles como programadores, es preciso tener en cuenta a la hora de diseñar la jerarquia de clases, que creemos un interfaz para la clase NavigatorFlow y esta interfaz es la usada dentro de Navigator, de esta manera los tests unitarios que vamos a escribir serán menos complejos a la vez que nuestro codigo sera mas fáil de mantener y sencillo de entender por otros programadores.

Gracias a la creación de la interfaz INavigatorFlow, podemos en la clase que contiene los tests unitarios, definir un objecto mock (NavigatorFlowMock) usando dicha interfaz e inyectando dicho objeto mock en nuestra clase Navigator antes de ejecutar los tests unitarios. El objecto mock creado implementará la misma interfaz que NavigatorFlow (INavigatorFlow), lo que nos ayudara a definir la respuesta a la clase Navigator.

namespace MockingFirstExampleTest
{
    ///

    /// Unit tests for Navigator class.
    ///

    [TestClass]
    public class NavigatorTest
    {
        ///

        /// This is the instance of the class under test.
        ///
        private Navigator navigator;

        ///

        /// Mock object of NavigatorFlow.
        ///
        private Mock flowMock;

        [TestMethod]
        public void TestNavigateSuccess()
        {
            var input = "MyInput";
            var expectedOutput = input + input;

            // define expectations of the mock object
            flowMock.Setup(flow => flow.DoNext(input)).Returns(input + input);

            // call to navigate method
            var output = navigator.Navigate(input);

            // check expectations
            Assert.IsTrue(output.Equals(expectedOutput));
        }

        /// 
        /// Set up the common stuff for the unit tests.
        ///
        [TestInitialize]
        public void SetUp()
        {
            // create the mocks objects
            flowMock = new Mock();

            // instantiates the class under test
            navigator = new Navigator(flowMock.Object);
        }
    }
}
 

El código anterior define una clase de tests unitarios para la clase Navigator, dicha clase contiene una instancia a Navigator y otra que es el objeto mock de la clase NavigatorFlow (flowMock). En el método SetUp, el cual se ejecuta antes de cada test unitario, lo que necesitamos es instanciar el objeto mock e inyectar éste mismo en el objeto de Navigator.

Asimismo, en los test unitarios (TestNavigateSuccess) se configura el comportamiento del mock, en este ejemplo se indica que el objeto mock va a recibir una llamada a DoNext con una entrada determinada, y le indicamos la salida (Returns) de dicha llamada. En este caso estamos haciendo uso de una librarías de mocking existente, hay montones de librerías que nos facilitan la vida para aplicar estas técnicas, además, se pueden definir varias salidas y distintos comportamientos en nuestros objetos mock, solo es necesario conocer la librería que vamos a usar. También es posible crear el objeto mock sin librerías pero nos obligará a escribir algo de cødigo en una clase aparte, sin embargo, hay circunstancias donde es mejor esta práctica que el uso de una librería.
Read On

Profundizando en Javascript

0 comentarios

Hoy quiero presentar un libro gratuito que me encontré hace unas semanas mientras realizaba una búsqueda aobre las nuevas tendencias en programación de frontales web. Dicho libro te presenta los conceptos básicos de la programación de un framework en javascript, además de mostrarte opciones decómo ha resuelto cierto problemas los principales frameworks comnocidos por todos.


Para ser sincero, me ha sido difícil entender todos los conceptos, he basado mi carrera profesional en la programación desde el lado de backend, y dejé el camino de javascript varios años atrás, cuando terminaba mis estudios, sin embargo, a día de hoy quiero ampliar conocimientos aunque sean teóricos de programación en el lado de frontend, me vendrá bien para el futuro.

Prototype, apply, prototypal inheritance, functional programming, ..., algunos conceptos nuevos y otros no tan nuevos para programadores experimentadosse mencionan en el libro. Lo importante para mí, me ha abierto el camino para empezar a profundizar en un lenguaje que tenía olvidado y que cada día va aportando nuevas herramientas, como ejemplo los nuevos frameworks MVC de los que un día hablaremos.

Si eres un apasionado del desarrollo web, un programador de frontend web experimwntado o quieres ser uno de alto nivel, este libro es de lectura obligada
Read On

Empirismo y Metodologías Ágiles

0 comentarios

Cada día que pasa palabras como Ágil, Scrum, Lean, Iteration, Sprints, .., se pronuncian más en entornos de desarrollo software, cada vez son palabras más familiares, cada vez hay más empresas que están acomodando o adaptando metodologías ágiles dentro de sus equipos al cargo de las soluciones software.

Tuve la oportunidad de conocer estos conceptos al comienzo de mi carrera profesional, desde el punto de vista del programador, y ya desde entonces me pareció un cambio drástico en lo aprendido previamente, pero tras lecturas sobre su teoría y su posterior puesta en práctica se iba consumando en mi interior una creencia hacia un cambio inmejorable y que sería claramente el futuro en la industria del software.

Desde hace unos meses tengo la oportunidad de poner en práctica el uso de metodologías ágiles en un pequeño equipo de desarrollo, pero desde el punto de vista de gestión. Es pronto para tomar conclusiones grandes, pero estos meses me han servido para ver que cada equipo es muy diferente,y cada equipo necesita sus propias herramientas para poner en práctica una metodología de desarrollo. Al principio, es muy importante una revisión constante para poder tunear herramientas, equipo y procesos para adaptarlos al entorno propio de trabajo, ningún equipo es igual y es muy importante tener la mente abierta para la adaptación constante.

En pocas palabras, hay que llevar el empirismo a su totalidad, trazar un proceso básico a seguir para el desarrollo, medir resultados para saber qué es necesario cambiar y proceder con los cambios de afinamiento. Con el paso del tiempo es preciso añadir al proceso básico nuevos pasos para la mejora del proceso de desarrollo y del propio equipo. Si un cambio provoca malos resultados es necesario deshacer el cambio o readaptarlo.

Pon en práctica tu proceso y adáptalo a aprtir de los resultados de forma continúa.

Read On

Cross-platform mobile dev definitivo?

0 comentarios

Me ha parecido curioso este artículo con el que me topé hace unos días, y es que siempre da la sensación de que a priori cada idea va a ser la cumpla todas las expectativas pero siempre acabo encontrando soluciones con aspectos que no me acaban de convencer, estaremos en esta ocasión ante la posibilidad de desarrollar lo mínimo posible para tener productos en múltiples plataformas?

Cross-platform mobile application development tutorial

Read On

Dale giros a la ruleta

2 comentarios

En la vida, cada asunto o aspecto es a veces como jugar a la ruleta. Lo que quiero decir es que tiras de la ruleta y lo que te toca tienes que asumirlo, tienes que acatarlo y realizar la tarea encomendada, y cuando te toca tirar varias veces seguidas es cuando llegas a pensar en que realmente no pareces dueño de tu vida, incluso te impide hacer otros asuntos que son de menor importancia pero de los que disfrutas incluso más.

Básicamente, estas palabras forman parte de un simil referente a lo que me ha pasado con mi blog. Realmente me gusta pensar y escribir en mi propio blog, pero siempre que tiraba de la ruleta no me salía la casilla de "redactar post para blog" sino que me tocaba cualquier otra cosa que encima no era más interesante pero que si más prioritario.

Con toda esta retaíla de cosas, lo que quiero decir es que voy a intentar recuperar el blog, ya le he cambiado el aspecto y espero al menos redactar un post cada semana. Además, no solo voy a postear temas de informática, software, desarrollo, ..... si no que esero ir llenando el blog con distintos posts de diferentes temáticas.

Tenía ganas de hacer una reseña de porqué el simil de la ruleta, y todo me vino a la cabeza cuando el otro día volví a ver la película de El Cazador (por cierto la recomiendo a todo el que no la haya visto) y quería sentirme como Robert de Niro, desafiar a que la ruleta rusa no va a acabar conmigo en lugar de caer en sus brazos hasta que me vuele la tapa, quiero acabar con ella, darle vueltas hasta que salga volando....
Read On