Design a site like this with WordPress.com
Get started

CodedUI Test & Jenkins

He necesitado integrar la ejecución de tests de interfaz con CodedUI Test para una aplicación de WPF con Jenkins.

El problema es que para poder ejecutar los test de interfaz es necesario una sesión interactiva iniciada. Con esa sesión se ejecutarán los test de interfaz que necesitan interactuar con el ratón y teclado. Lamentablemente esta sesión está activa mientras tengas por ejemplo una conexión por escritorio remoto (RDC)  abierta, pero claro, no queremos tener que abrir una RDC para pasar los tests.

Pues ha sido duro pero lo he conseguido, y aquí os dejo los pasos que he hecho para hacerlo

Nota: El Jenkins que hemos usado NO se estaba ejecutando como servicio así que si tienes Jenkins corriendo como servicio no se si esto te puede ayudar. Continue reading “CodedUI Test & Jenkins”

WaveEngine 2.0 ya está aquí

Es un orgullo el formar parte del equipo que está haciendo cosas como esta:

Wave Engine

Hoy, en apenas unas horas saldrá la nueva versión del motor de video juegos multiplataforma que estamos construyendo y que ya cuenta con un montón de usuarios que están haciendo cosas impresionantes.

Esperamos que disfrutéis usándolo tanto como nosotros haciéndolo.

P/D: Aún estáis a tiempo de encontrar el huevo de pascua que está escondido en la web. 😉

Git para usuarios de TFS

Los ALMRanges publicaron un pequeño libro para contarnos el uso de Git a usuarios acostumbrados a usar sistemas de control de versiones centralizados como TFS y subversion.

Me volví a armar de valor para traducirlo al castellano y aquí lo tenéis.

Espero que os guste.

Noticia en el blog de los ALM Rangers

Control de Versiones con TFS Parte 4 – Git para usuarios de TFVC

Un detalle de la parametrización de CodedUITests con CSV

Hay un detalle que no nos cuentan en MSDN  Creating a Data-Driven Coded UI Test

Resulta que me he puesto a crear el primer test parametrizado y en mi csv tenía este contenido:

User,Passwd
1111,pass0000
7777776,4444

Cuando se ejecutaba el test, en la row del test paremetrizado que debería obtenerme el “pass0000”, me estaba obteniendo un string vacío:

Parametrized CodedUITest

Para que no ocurra esto, simplemente hay que modificar el archivo csv y añadirle comillas a los valores que queremos que nos devuelva:

User,Passwd
“1111”,”pass0000″
“7777776”,”4444″

Me ha traido loco durante dos horas, espero que a alguien más le sirva.

Juan María Laó Ramos

 

Primeros pasos con Xamarin.UITests para aplicaciones híbridas

Hemos tenido la oportunidad de empezar a “trastear” con Xamarin.UITest para validar la interfaz de usuario de una aplicación hecha con Cordova, y desplegarlo en Test Cloud para correr los tests en varios dispositivos físicos.

Vamos a partir de la base de que habéis creado un proyecto de Xamarin.UITest, lo primero que debemos hacer es arrancar un emulador o un dispositivo físico para desplegar la app y ejecutar los tests. Para arrancar la aplicación, una vez que el emulador o el dispositivo físico esté arrancado, sólo tenemos que añadir este código:

public class AppInitializer
{
    public static IApp StartApp(Platform platform, Xamarin.UITest.Configuration.AppDataMode mode = Xamarin.UITest.Configuration.AppDataMode.Auto)
    {
        if (platform == Platform.Android)
        {
            return ConfigureApp
                .Android
                .EnableLocalScreenshots()
                .ApkFile("../../../Apps/myapp.apk")
                .StartApp(mode);
        }

<pre><code>    return ConfigureApp
        .iOS
        .EnableLocalScreenshots()
        .AppBundle(&amp;quot;../../../Apps/myapp.app&amp;quot;)
        .StartApp(mode);
}
</code></pre>

}

Fijáos que vamos a testar la UI de una aplicación multiplataforma desarrollada con Cordova para iOS y Android, por lo que hemos decidido usar un único punto de entrada para ambas aplicaciones. El motivo de todo esto es crear un conjunto de tests multiplataforma para Android e iOS. Así que con esta simple clase, en cada clase de test que tengamos, el método de “Setup” será algo parecido a:

[SetUp]
public void BeforeEachTest()
{
    app = AppInitializer.StartApp(platform);
}

De este modo, podemos asumir que antes de que se ejecute cada test la aplicación estará arrancada para poder ir navegando por ella a partir de la pantalla de inicio. Así estamos listos para empezar a testar la interfaz de usuario.

El flujo de trabajo es simple:

  1. Esperar hasta que el elemento con el que queremos interactuar aparece en la interfaz:Con esta línea estamos pidiéndole a la aplicación que se espere hasta que aparezca un div en el componente WebView. El método “WaitForElement” tiene varias sobrecargas con diferentes parámetros en los que le podemos modificar el timeout, etc. Esto puede ser útil en algunos casos, como por ejemplo, cuando el div se muestre después de una operación que pueda tardar más tiempo de lo normal
    this.app.WaitForElement(c =&gt; c.WebView().Css("div.MyStyleClass"));
  1. Interactuar con la UI:Este método nos permite simular taps en la aplicación. La interfaz IApp de Xamarin.UITest ofrece bastantes métodos con los que podemos interactuar con la app como Scrolldown, PressEnter, PinchToZoomIn, etc…
this.app.Tap(c =&gt; c.WebView().Css("div.MyStyleClass "));</li>
  1. Esperar a lo que queremos testar. Vamos a asumir que después de hacer tap en el div que hemos estado esperando, aparecerá otro div. Así que esperamos a que aparezca el segundo div:
this.app.WaitForElement(c =&gt; c.WebView().Css("div.MySecondDivClass"));

El test completo tiene esta pinta:

[Test]
public void AfterTappingDiv2MustBeShown()
{
    this.app.WaitForElement(c =&gt; c.WebView().Css("div.MyStyleClass"));
    this.app.Tap(c =&gt; c.WebView().Css("div.MyStyleClass"));
    this.app.WaitForElement(c =&gt; c.WebView().Css("div.MySecondDivClass"));
}

En este punto tenemos un test que podemos ejecutar en la misma aplicación en ambas plataformas, iOS y Android, y esperamos que en ambas plataformas se comporte de la misma forma.

En algunas ocasiones, por cada test que queramos hacer necesitaremos “ver” el código de la interfaz de usuario. Esto lo conseguimos usando el método “Repl()” que está en la interfaz IApp. Cuando invoquemos a este método aparecerá una consola en nuestro pc:

Open Repl

En esta consola podemos llamar a cualquier método de la interfaz IApp. Es muy útil ya que podemos usarlos para ir creando paso a paso los test que queremos ir haciendo.

Por ejemplo, si esperamos a un elemento que no aparecerá en la UI, la consola mostrará algo así:

Repl Do Not Found Div

Sin embargo, si el elemento existe, REPL nos mostrará el HTML del elemento.

Con esta funcionalidad tan simple somos capaces de transformar tests manuales en tests automáticos. Con esto conseguimos transformar un trabajo muy costoso en un trabajo totalmente automatizado.

Artículo original publicado en el blog Xamarin Team de Plainconcepts

[Evento CartujaDotNet] ALMdeando

El próximo Miércoles 11 de Marzo de 2015, desde Cartuja .NET organizamos una sesión de charlas en las que veremos diferentes tecnologías para mantener y mejorar los procesos de desarrollo de software.

Dragon¿Te apuntas?

Fecha

El evento tendrá lugar el próximo Miércoles, 11 de Marzo de 19:00h a 21:00h. Las sesiones tendrán una duración de entre 30 minutos y 45 minutos con descanso intermedio de 5 minutos.

Lugar

Tendrá lugar en el Cloud Pointing de Sevilla situado en el Parque Empresarial Nuevo Torneo. Tenéis la información exacta del lugar a continuación:

c Biología, 12, Edificio Vilamar 2, 3ª Planta
Parque Empresarial Nuevo Torneo
41015 Sevilla

Agenda y Ponentes

– Utilizando Integración continua con Apps Xamarin (Javier Suárez) (45 minutos)

En esta sesión Javier Suárez nos hablará de integración continua con Apps Xamarin. La integración continua es fundamental en el desarrollo de software, independientemente de la plataforma. Detectar problemas tan pronto como sea posible es una gran victoria, sobre todo en el mundo móvil. Veremos cómo ejecutar pruebas como parte del proceso de Build, que cubren las pruebas unitarias, etc.

– Continuous Delivery con Release Management (Ibon Landa) (45 minutos)

En esta sesión veremos qué papel juega Release Management en el ciclo de vida de la aplicaciones y como lo podemos utilizar para implementar de principio a fin un pipeline de release para nuestras aplicaciones.

Después de una introducción a los conceptos más básicos de Continuous Delivery intentaremos ver de la forma más práctica posible la funcionalidad que aporta Release Management.

– Making better tests (Juan María Laó Ramos) (30 minutos)
En esta sesión Juanma nos contrará algunos trucos y buenas prácticas que ha aprendido arrastrándose por los barrizales de la programación, más que nada para evitar tener que poner muchas lavadoras después de llegar a casa y tener más tiempo para los suyos.

Más información

[Cartuja .NET] Quedada

Cartuja .NET

En CartujaDotNet vamos a realizar una quedada informal para charlar abiertamente sobre tecnologías Microsoft, herramientas utilizadas, intercambiar impresiones, etc. Además, se analizarán las próximas charlas ya planteadas y los eventos confirmados entre otros temas de interés.

No hace falta confirmar asistencia, y por supuesto será gratuito.

¿Te apuntas?

A continuación tienes disponible la fecha, hora y lugar:

Resumen de la Mesa redonda de TDD con Cartuja .NET

Ayer desde Cartuja .Net hicimos una mesa redonda sobre TDD y la conversación fue muy, pero que muy ilustradora sobre todo para mí.

Aquí mi resumen:

Tras hablar sobre las últimas novedades que habían aparecido en la comunidad .NET tras las presentaciones de #vsconnect y conseguir centrarnos, comenzamos con una explicación sobre qué es TDD muy corta, apenas 30 segundos:

“TDD consiste en que cuando vamos a escribir código, hacer primero un test que falle para el código que queremos escribir, luego el mínimo código que hace que el test se ponga verde, y refactorizar el código que hemos escrito”

Seguimos con la duda que yo tengo sobre ese ciclo, y es que, como ya comenté en otro post, el ciclo es incompleto, falta una primera fase de “pensar” antes incluso de escribir ese primer test.

Es decir, tomar muchas veces papel y lápiz, y dibujar la “arquitectura” que creemos debe ser. Una vez que tenemos separadas las responsabilidades que el sistema debe tener, cogemos una de esas clases y podemos empezar a aplicar TDD sobre esa clase.

Suele ocurrir que al escribir ese test y escribir el código se encuentran dependencias que antes no se habían tenido en cuenta. Es decir, responsabilidades ocultas y suele generar en otra clase que tendremos que mockear para poder seguir avanzando en el ciclo de TDD y avanzando en el nuestro trabajo.

Y aquí llego la primera disputa sobre el concepto de que “la arquitectura emerge“. Tras un rato de dialogo sobre eso, saqué la conclusión de que esa arquitectura que emerge no es la arquitectura del sistema completo, sino la arquitectura del contexto en el que está centrado ese test.

Mi conclusión particular sobre este punto, es que aplicando TDD nos obligamos a pensar en responsabilidades, nos obligamos a seguir el principio de una única responsabilidad y esto, paso a paso, test a test, nos ayuda a averiguar si aquella arquitectura que teníamos en la cabeza, que dibujamos con papel y lápiz en un primer momento es adecuada o no. Como corolario podemos decir que si nos resulta difícil seguir avanzando en ciclos cortos de test-code-refactor, hay que replantearse esa arquitectura ya que parece que esa elección no es adecuada, y eso es bueno, ya que al menos hemos encontrado una forma de no hacerlo.

Tras unas cuantas experiencias que compartimos, buenas y malas, continuamos con la conversación sobre las bonanzas del testing, integración continua, TFS, Team City, programación defensiva, y un largo etcétera. Todos estamos de acuerdo sobre las ventajas, sabemos que es bueno hacer test. Hasta que alguien nos hizo caer en la cuenta de que desde hacía un buen rato no estábamos hablando sobre TDD sino de testing. Así que recondujimos la conversación con el tema de la práctica y la maestría.

Obviamente no es lo mismo empezar a aplicar TDD que llevar tiempo aplicándola. La famosa curva de aprendizaje es en realidad así:

Tenemos un nivel de productividad (verde) y cuando empezamos hay una bajada de productividad importante y empezamos el camino de la práctica hasta que volvemos a alcanzar el mismo nivel de productividad que teníamos antes. En realidad esto pasa con todas las tecnologías y técnicas que aprendemos a lo largo de nuestra carrera, y es en esa parte de la curva cuando optamos por abandonar o seguir con el camino que hemos iniciado.

El problema con TDD es que para mentes como yo, ese proceso es duro y es muy fácil desistir y abandonar, el lado oscuro siempre nos tienta, es más fácil, más rápido y más seductor no seguir por el camino de TDD.

Continuamos con la pregunta de ¿hay que hacer TDD siempre? En el camino del aprendizaje, nos vamos dando cuenta de que es descabellado hacer TDD en todo. En ese camino se aprende a ser pragmático y a ajustarse a las necesidades del proyecto y del momento en el que estamos trabajando. Pero sobre todo, se aprende en ese camino a diseñar. TDD no es sólo una herramienta de testing, es mucho más, es una herramienta de diseño. En el camino de maestría de TDD se aprende sobre todo a diseñar, y con el tiempo se consigue empezar a acertar en esa primera “arquitectura” que pintamos en un papel. Normalmente los problemas que resolvemos suelen ser parecidos, y vamos mejorando esa arquitectura que dibujamos al principio.

Como última ventaja que le veo a TDD es que cuando no tenemos claro cómo solucionar un problema, TDD ayuda a encontrar una solución, empezando a escribir ese primer test de aquello que queremos programar pero no tenemos claro cómo hacerlo. Conseguimos tener un diseño desacoplado, abierto a la extensión y cerrado a la modificación, etc.… De esta forma cuando averiguamos qué es lo que hay que hacer nos es más sencillo modificar esa arquitectura.

Después de todas las experiencias que vimos, es curioso que siempre los que suelen ir a este tipo de eventos, y tu que estás leyendo esto, son siempre profesionales que buscan formas de hacer mejor su trabajo.

Quiero dejaros algunos nombres y libros que surgieron en la conversación, se que me falta alguno, así que si te acuerdas déjamelo en los comentarios:

Muchas gracias a Cartuja .NET por reunir a todos los que allí nos juntamos, ha sido una tarde muy agradable y tengo la sensación de que todos nos quedamos con ganas de más.

Estoy deseando ver la visión de cada uno que asistió, bien en los comentarios de este humilde blog o con referencias a los blogs de los que allí nos juntamos. No quiero señalar http://javiersuarezruiz.wordpress.com/, http://www.variablenotfound.com, http://cartujadotnet.es/

Se me olvidó comentar que mañana es el de Global CodeRetreat http://globalday.coderetreat.org/

En Madrid lo tienen preparado: http://madridcoderetreat.wordpress.com/

Si podéis verlo seguro que os gustará.