Debuggeando Procesos y Servicios desde el momento de su ejecución.

Depurar procesos, servicios, etc es una tarea común en Software Development in Test y Development en si, pues nos permite aislar los bugs para de esta forma poder corregirlos.

La tarea a simple vista es simple, pues si queremos depurar procesos corriendo simplemente se utiliza Debug->Attach To Process, escogiendo el proceso en cuestión y podemos depurar como se desee.

El problema radica cuando el inicio de un proceso o ejecutable no depende de nosotros, como ser un servicio, o un worker process, o procesos en lote que se inician aleatoriamente, y el problema o crash ocurre directamente al momento de tan solo iniciarlos no dando tiempo para poder hacerles attach.

En este caso existe una solución simple:

1. Abrir el registro del sistema: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
2. Ejemplo, queremos que el proceso mspaint.exe se inicie para ser depurado desde un principio, para lo cual configuramos como se ve en la figura.
   
3. En este caso queremos que nuestro debugger por defecto sea Visual Studio, para lo cual creamos una clave de registro del tipo string que se llame Debugger el cual contiene vsjitdebugger.exe como se muestra en la figura:
   
4. A partir de este momento cada ves que se inicie nuestra aplicación se iniciará preguntando en que proyecto de Visual Studio nuestra aplicación puede ser depurada. Esto es aplicable para debuggers como Procdump. y windbg y de esta forma no perderemos los bugs que se producen nada más al iniciarse la aplicación

Nota: En servicios es necesario cambiar su modo a interactivo para de esta forma poder depurarlos de forma adecuada, esto se hace simplemente configurando en services.msc, de acuerdo a lo requerido. Pueden existir casos en que el servicio se inicia en una sesión distinta a nuestra sesión, en estos casos debe aplicarse debugging remoto vía pipes o vía tcp, el cual es aplicable a Windows Debugger, este caso se verá más adelante (especialmente pasa con Windows 8.1)

Testeo Combinatorial de APIs, + Combinando Reflection.

Testear librerias y API, puede llegar a ser un trabajo tedioso debido a la cantidad de parámetros y sus posibles combinaciones que pueda soportar, el presente artículo muestra como se puede testear un método, CreateFile con sus diferentes posibles combinaciones.

Comenzamos escribiendo un algoritmo que devuelve las posibles combinaciones de diferentes objetos, en este caso no especificaremos ningún tipo pues necesitamos que nuestro algoritmo sea lo más genérico posible.

La ventaja del algoritmo mostrado es su generalidad, pues no necesita pasarle tipos específicos. Un ejemplo de uso del algoritmo anterior, puede darnos la potencia combinando con Reflection como se muestra el ejemplo en el cual estamos testeando FileCreate(string Path, int bufferSize, FileOptions).

Generamos una combinatoria con todos los posibles parametros el cual nos da casi total cobertura del mismo.

Como se ve el algoritmo se adaptaría automáticamente a cualquier cambio en los tipos enumerados en FileOptions, el cual también es aplicable a Actions, la salida del algoritmo anterior seria la combinatoria:

Dado que este algoritmo soporta objetos sin tipo específico es posible combinar tipos del tipo MethodInfo, para invocar acciones genéricas de tal forma generar métodos de test más poderosos a través de un assembly adaptador de test.

El objetivo de este artículo fué mostrar la potencia de nuestros test al combinar Reflection con test Combinatoriales, para lograr un gran porcentaje de cobertura. Se dará un ejemplo de como lograr este objetivo en artículos más adelante.

Capturando tráfico webservices del dispositivo móvil desde fiddler.

Como sabemos Fiddler es una herramienta muy poderosa para captura de tráfico Web/WebServices.

Dada la naturaleza de la aplicación Fiddler, esta inicia como un servidor proxy, razón por la cual podemos configurar aplicaciones externas o de diferentes dispositivos con su proxy redirigido hacia el equipo que tiene fiddler iniciado.

1. Iniciar Fiddler.
2. Ir al menú Tools->Options->Connections->Allow Remote Computers to Connect.
   
3. Averiguar la IP del equipo que tiene fiddler iniciado, usando IPConfig por ejemplo.
4. Configurar el dispositivo móvil para que el tráfico pase por el servidor fiddler en la imagen se ve 192.168.0.2, el cual deberia ser 192.168.0.13 : 
   
5. En este momento estamos listos para capturar tráfico web / webservices del dispositivo móvil (Ejemplo app Weather en iPhone).
   

Simulando retraso de respuesta de la red en sistemas web.

Fiddler es una herramienta poderosa para capturar tráfico http, pero al mismo tiempo permite simular diversas situaciones, como por ejemplo retraso en la entrega del paquete http.

Muchas veces en software testing necesitamos simular retrasos en el tráfico de red, esto con el fin de testear el comportamiento de nuestra aplicación bajo estas circunstancias.

Ejemplo: Queremos simular retraso de 10 segundos en la operación GET http://www.la-razon.com

Para realizar aquello necesitamos AUTORESPONDER, una característica poderosa de fiddler, bajo los siguientes pasos:

1. Abrimos fiddler.
2. Ir al Tab Autoresponder.

Configurar que el sitio: http://www.la-razon.com :

Una ves realizados estos pasos cada ves que se acceda a http://www.la-razon.com/ sufrira un retraso de 10 segundos, dado que el parametro delay esta en formato de milisegundos. Esto es aplicable para web services que soportan proxy.