Depuración remota sobre SSH

      No hay comentarios en Depuración remota sobre SSH

Depuración remota sobre SSHDespués de la entrada sobre como instalar NetCore en Linux (o sobre cualquier otro entorno), el siguiente paso lógico es poder depurar nuestro código mientras corre en Linux, como lo haríamos sobre Windows.

Para esto, tenemos 2 opciones, utilizar Visual Studio Code o Visual Studio para hacer depuración remota sobre ssh,. En este caso, vamos a utilizar la segunda opción, ya que en la mayoría de los casos en los que usemos NetCore, correrá en un servidor sin interfaz gráfica.

Para ello, lo primero que necesitamos es que nuestro equipo Linux tenga un servidor SSH habilitado, esto es lo que ocurre habitualmente, pero en caso de no haberlo puesto durante la instalación del OS, se puede añadir sin problema.

Una vez dicho esto, vamos con ello.

Proyecto

Para poder seguir la entrada, lo primero que vamos a hacer es crear un proyecto de consola de NetCore:

consola .net core

Al que le vamos a poner este código:

Es un código muy simple, ya que la finalidad es probar la  depuración remota sobre SSH, simplemente, ejecutara 100 veces el Console.WriteLine, mostrando por pantalla la hora en la que estamos. Con esto, vamos a ganar el tiempo que necesitamos para asociarnos al proceso remoto. Si lo ejecutamos tal cual, tendremos una salida parecida a esta:

Ejemplo depuración remota

Una vez que tenemos esto, lo colocamos en nuestro servidor, y vamos al lío!!!

Depuración remota sobre SSH

Visual Studio 2017 añade varias opciones para asociarnos a un proceso en ejecución, para ello, desde el menú “Depurar”, vamos a la opción “Asociar al proceso…”, o pulsamos el atajo “Ctrl+Alt+P

Asociar al proceso

Eso, nos va a mostrar una nueva ventana:

VentanaAsociar

En ella, seleccionamos el tipo de conexión SSH y ponemos la dirección del servidor. Con eso, al pulsar actualizar, se nos mostrará una nueva ventana para pedirnos los datos de conexión:

ventanaDatosSSH

Basta con que rellenemos los campos con los valores de conexión a nuestro servidor, y acto seguido,  (igual hay que pulsar sobre actualizar) se nos mostraran los procesos activos en el servido:

ProcesosActivos

Vamos a utilizar la opción de filtro, para buscar los procesos “dotnet”:

filtro

Seleccionamos el proceso que queremos depurar, y esto nos lanza una ultimo ventana, en la que nos pide que le indiquemos como queremos depurar:

Modo

Tenemos que seleccionar “Managed”. Al seleccionar el proceso, vemos que se asocia a la ejecución, y nos permite depurar el ejecutable de manera remota sobre ssh:

Breakpoint

Aclaraciones

En caso de necesitar instalar componentes, Visual Studio se encarga de descargarlos e instalarlos sin necesitar nada por nuestra parte. Esto es así siempre, salvo que nos falten paquetes que se consideran básicos, como pueden ser el servidor SSH, curl o wget, o unzip. En caso de que nos falte alguno o todos ellos,  debemos instalarlos nosotros, o cuando intentemos asociarnos se mostrara un error parecido a este:

Error Paquetes

/home/username/.vs-debugger/GetVsDbg.sh -v vs2017u5 -l “/home/username/.vs-debugger/vs2017u5”

Esto se soluciona fácilmente instalando todo lo que nos falte con el comando:

sudo apt-get install openssh-server unzip curl

Espero que haya sido de utilidad, aunque le daremos uso en siguientes entradas cuando creemos DLL de C++ y las consumamos en NetCore, para poder comprobar en caso de que tengamos algún problema.

Como instalar .NetCore en Linux

      No hay comentarios en Como instalar .NetCore en Linux

.NetCore en Linux

Después de tantas entradas hablando sobre .NetCore y lo que me gusta utilizar una herramienta multiplataforma, hoy vamos a ver como instalar el SDK de .NetCore en Linux. Esto puede parecer algo complicado, pero en realidad es muy muy fácil. En este caso, vamos a utilizar para el ejemplo una distribución Debian 9.5.

Instalando .NetCore en Linux

En primer lugar, es necesario instalar el paquete “apt-transport-https”, el cual nos permite conectar con los repositorios de Microsoft:

sudo apt-get install apt-transport-https

Después, vamos a registrar las claves de Microsoft dentro de el registro de claves seguras, de cara a que no nos de advertencias al utilizar HTTPS los repositorios, para ello, escribimos las siguientes instrucciones en la terminal (En caso de no utilizar Debian sino otra distro, puedes consultar las instrucciones aquí):

sudo wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg –dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
sudo wget -q https://packages.microsoft.com/config/debian/9/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list

Una vez hecho esto, ya hemos añadido los repositorios a nuestra maquina, con lo cual, solo nos queda actualizar la lista e instalar el SDK:

sudo apt-get update
sudo apt-get install dotnet-sdk-2.1

Con estos sencillos pasos, ya tenemos el SDK instalado en nuestro equipo con Debian, y podemos empezar a trabajar con el.

Probando el SDK

Una vez tenemos el SDK instalado, vamos a comprobar que todo funciona correctamente, para ello, vamos a descargar el proyecto de las entrada Venciendo el miedo a las pruebas unitarias en .Net , pero también podríamos hacerla con Rompiendo limites: Mocking en las Pruebas Unitarias .Net o cualquiera de las que usan .NetCore.

*NOTA: Voy a asumir que no todo el mundo usa git, por los que utilizaré los enlaces https, en caso de hacerlo con git, simplemente seria necesario hacer un “git clone” en vez de una descarga wget.

Vamos con el primero, lo primero, es descargarlo, descomprimirlo y entrar al proyecto:

wget https://github.com/JorTurFer/PostPruebasUnitariasCore/archive/master.zip
unzip -a master.zip
cd PostPruebasUnitariasCore-master

Una vez dentro de la carpeta, vamos a construir el proyecto con:

dotnet build *.sln

Si todo va bien, veremos algo como esto:

build result

Y vamos a comprobar que las pruebas unitarias se ejecutan correctamente accediendo a ellas y ejecutándolas con:

cd PruebasUnitarias
dotnet test *.csproj

Lo que nos debería mostrar algo como esto:

test result

En próximas entradas, mostraré como instalar nuestros programas como servicio .NetCore en Linux.

Rompiendo los limites: Mocking en las Pruebas Unitarias .Net

MockingHoy por fin os traigo la unión entre las Pruebas Unitarias y la Inyección de Dependencias, el “Mocking“. ¿Que es el “Mocking” te preguntarás?, pues es la técnica utilizada para simular objetos en memoria con la finalidad de poder ejecutar pruebas unitarias.

Esto, es especialmente útil cuando utilizamos recursos externos como bases de datos o servicios de mensajería, o cualquier cosa en general que no queramos o no podemos ejecutar durante las pruebas unitarias.

Sin mas preámbulos, ¡vamos con ello! En primer lugar, he reutilizado el proyecto Entity Framework Core “Code First” para partir de tener el contexto de datos creado. Ademas, he añadido una clase “GeneradorInformes” (la cual cumple el patrón de Inyección de Dependencias en el constructor) y una clase “EmailSender” que implementa la interfaz “IEmailSender”:

Proyecto

El resumen del funcionamiento básico, es que GeneradorInformes recibe las dependencias del contexto de datos y el servicio de correo, y al llamar al método “GenerarInforme(string,string)” se obtiene el informe del cursos y alumnos del profesor indicado, y se envía al correo indicado. En caso de que el informe se genere correctamente y se envíe, retornamos un true, en caso contrario un false.

Pruebas Unitarias y Mocking

Generaremos un proyecto de pruebas unitarias en nuestra solución y añadimos a nuestro proyecto de pruebas el siguiente paquete:

Moq.Net

O por consola:

PM-> Install-Package Moq -ProjectName “NombreProyectoPruebas”

Este paquete esta alineado con .NetStandard, en concreto .NetStandard 1.3, por lo que se puede utilizar indistintamente en .Net Framework o en .Net Core. Una vez que lo tenemos todo listo, vamos a crear nuestra prueba unitaria para GeneradorInformes.

Analicemos la clase de pruebas. En primer lugar, tenemos 2 objetos de tipo “Mock<T>” , declarados a nivel de clase, esto es debido a que vamos a utilizarlos en las 2 pruebas, y así nos ahorramos tener que construirlos 2 veces, aligerando así la carga.

Mock<IEmailSender>

Lo siguiente que tenemos, es el constructor. En él, se inicializan los objetos Mock, vamos de uno en uno:

Mediante el método “Setup”, le estamos indicando el comportamiento que debe tener cuando llamemos el método Enviar(string,string) de la interfaz. Cabe destacar que “It.IsAny<string>()” esta indicando que este Mock se aplicara ante cualquier entrada de tipo string, pero podríamos indicarle un string concreto, por ejemplo:

Con este segundo código, solo aplicaría el Mock si el primer string es “FixedBuffer”, pudiendo definir así diferentes comportamientos ante diferentes entradas ya que podemos llamar tantas veces al método Setup como queramos.

Mock<PostMockingDbContext>

En este caso, no vamos a generar generar un comportamiento en concreto, sino que vamos a generar un contexto de datos falso. Lo primero para eso, es crear una colección de datos:

Como se puede ver, simplemente estamos creando la colección que luego convertiremos en el contexto de datos. Una vez que tenemos los datos, vamos a crear el Mocking del DbSet, que como se puede ver, simplemente consiste en relacionar la colección que acabamos de crear con el objeto Mock<DbSet<Profesor>>.

En el caso de necesitar mockear más tablas, solo tendríamos que repetir el proceso con todas las tablas que nos interese. Una vez que hemos acabado de generar todos los datos que tendrá nuestro contexto, asignamos los DbSet mokeados, vamos a crear por fin nuestro “Mock<PostMockingDbContext>”:

Esto lo conseguimos diciéndole en el Setup que ante un acceso a la tabla “Profesores”, devuelva el objeto mock que acabamos de crear.

Una vez que tenemos creados nuestros dos objetos “Mock<T>” para las pruebas, veamos las pruebas:

Como se puede ver, el funcionamiento es exactamente igual que sería en nuestro proyecto en producción, pero en vez de pasarle el PostMockingDbContext y EmailSender, las cuales pueden no estar disponibles para las pruebas, le pasamos sus respectivos Mock, de modo que siempre podemos prever el comportamiento, pudiendo hacer pruebas que sean fiables, sin necesidad de que se tenga acceso a recursos externos. Esto es especialmente útil si se emplean herramientas de CI como Travis o AppVeyor, ya que no van a tener acceso a esos recursos. De hecho, os dejo el enlace a una colaboración que hice hace unos meses hablando sobre AppVeyor y la integración continua.

Ademas, como dato adicional, podemos ver la salida de consola del test unitario, donde ademas de saber que se ha ejecutado correctamente, podríamos ver el reporte:

report

Como habitualmente, dejo el enlace de GitHub para descargar el proyecto y poder probarlo, en este caso, desarrollado en .Net Core. Para ampliar información, dejo también la documentación de Moq.Net.