DEV Community: Manuel Dávila Alarcón

Todo lo que necesitas saber para publicar NuGets

Manuel Dávila Alarcón — Mon, 15 Dec 2025 15:53:23 +0000

En el artículo anterior, analizamos cómo sobrevivir al infierno de las dependencias desde la perspectiva del consumidor. Sin embargo, el verdadero salto de calidad en una carrera técnica ocurre cuando dejas de ser quien descarga paquetes y te conviertes en quien los diseña.

El problema fundamental que resuelve NuGet no es simplemente "bajar DLLs", sino la violación del principio DRY (Don't Repeat Yourself) a nivel arquitectónico.

Imagina el escenario clásico donde tienes una clase AuditLog.cs o un StringUtils.cs. Al iniciar un nuevo microservicio, lo más "rápido" es copiar y pegar el archivo. Seis meses después, encuentras un bug crítico de seguridad en esa clase. Ahora te enfrentas a la pesadilla de auditar y parchear 10 repositorios distintos manualmente.

La solución profesional es empaquetarlo y vamos a descubrir como hacerlo con NuGet.

1. NuGet Library

Crear una librería no requiere magia, requiere metadatos. El archivo .csproj deja de ser un simple archivo de configuración para convertirse en el manifiesto del producto.

Si el .dll es el producto, el .csproj es la etiqueta de envío; sin ella, nadie sabrá qué es, cómo se usa ni si es seguro.

Aquí tienes una configuración explicada:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <!-- MULTI-TARGETING -->
    <!-- netstandard2.0 para compatibilidad máxima (Legacy) -->
    <!-- net8.0 para optimizaciones modernas -->
    <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>

    <!-- IDENTIDAD -->
    <PackageId>MyCompany.Common</PackageId>
    <Version>1.0.0</Version>
    <Authors>Equipo de Arquitectura</Authors>
    <Company>Mi Empresa S.A.</Company>
    <Description>Librería base para validaciones y logs estandarizados.</Description>

    <!-- ASSETS -->
    <PackageIcon>icon.png</PackageIcon>
    <PackageReadmeFile>README.md</PackageReadmeFile>

    <!-- SEGURIDAD -->
    <!-- Garantiza que el binario sea idéntico bit a bit en cada build -->
    <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>

    <!-- ORGANIZACIÓN -->
    <PackageTags>logs;validation;common;architecture</PackageTags>
    <PackageOutputPath>./nupkg</PackageOutputPath>

    <!-- REPOSITORIO Y LICENCIA -->
    <RepositoryUrl>https://github.com/mi-empresa/my-common-lib</RepositoryUrl>
    <RepositoryType>git</RepositoryType>
    <PackageLicenseExpression>MIT</PackageLicenseExpression>

    <!-- BUILD -->
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>

  <!-- DEPENDENCIAS -->
  <ItemGroup>
    <PackageReference Include="Serilog" Version="4.0.0" />
  </ItemGroup>

  <ItemGroup>
    <!-- Empaquetamos los assets visuales dentro del nupkg -->
    <None Include="..\images\icon.png" Pack="true" PackagePath="\" />
    <None Include="..\README.md" Pack="true" PackagePath="\" />
  </ItemGroup>

</Project>

¿Por qué cada línea importa?

🎯 El Dilema del Target (Multi-targeting)

¿Tu empresa tiene proyectos viejos en .NET Framework y nuevos en .NET 8? No elijas uno.
Usando <TargetFrameworks> (en plural), compilas para ambos.

netstandard2.0: Corre en casi cualquier cosa (incluso .NET Framework 4.6.1+).
net8.0: Aprovecha las optimizaciones modernas de rendimiento. NuGet entregará automáticamente la DLL correcta según el proyecto del consumidor.

📁 Assets (Icon & Readme)

Agrega personalización y documentación de tu package (al menos si será público).

PackageIcon: Incluye tu logo (png 128x128).
PackageReadmeFile: El README.md se mostrará en la pestaña de NuGet en Visual Studio. Es tu oportunidad de explicar cómo usar la librería antes de que el dev se frustre y la desinstale.

🔒 Builds Deterministas

¿Te ha pasado que compilas lo mismo dos veces y el hash cambia?
<ContinuousIntegrationBuild>true</ContinuousIntegrationBuild> garantiza que si el código no cambia, el binario es idéntico bit a bit. Esto es crucial para validaciones de seguridad y cachés en entornos corporativos.

📦 Dependencias Transitivas

Al incluir Serilog en el ItemGroup, cualquiera que instale tu paquete lo recibirá automáticamente. ¡No obligues a tus usuarios a instalar dependencias manualmente!

🏷️ Etiquetas de repositorio

Si omites esto, tu paquete se verá "sospechoso" en los feeds. Vincular el código fuente demuestra profesionalismo y permite a los usuarios (o auditores) navegar al repo original con un clic.

🗂️ Estrategia de versionamiento

Si bien aquí usamos una versión estática (1.0.0), en entornos profesionales te sugiero automatizar esto con herramientas como MinVer, que calculan la versión semántica basándose en tus Git Tags.

⚖️ Licenciamiento Legal

Open Source: Usa <PackageLicenseExpression> con códigos estándar como MIT, Apache-2.0, etc.
Propietario/Empresarial: Usa <PackageLicenseFile> y apunta a un archivo LICENSE.txt dentro del paquete para proteger la propiedad intelectual de tu empresa.

2. NuGet Tools

Mientras que las librerías se integran en tu aplicación, las NuGet Tools son aplicaciones que corren junto a tu aplicación. Piensa en herramientas como dotnet-ef.

Podemos crear nuestras propias herramientas corporativas (por ejemplo, un Scaffolder para crear microservicios con la arquitectura de la empresa) empaquetando una aplicación de consola.

PackAsTool

La diferencia técnica radica en la propiedad <PackAsTool>. Esto le dice a NuGet que el paquete contiene un ejecutable, no una librería para referenciar.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>

    <!-- Convierte la consola en una herramienta distribuible -->
    <PackAsTool>true</PackAsTool>
    <!-- Este es el comando mágico que escribirás en la terminal -->
    <ToolCommandName>my-scaffolder</ToolCommandName>

    <PackageId>MyCompany.Scaffolder</PackageId>
    <Version>1.0.0</Version>
    <PackageOutputPath>./nupkg</PackageOutputPath>
  </PropertyGroup>

</Project>

Cuando un desarrollador instala este paquete, el ejecutable se añade al PATH del sistema y queda disponible como un comando nativo.

# 1. Instalación Global
dotnet tool install -g MyCompany.Scaffolder

# 2. Ejecución
my-scaffolder "NuevoServicio"

💡 Para evitar la instalación global puedes usar Local Tools (dotnet new tool-manifest) para asegurar que todos usen la misma versión mediante dotnet tool restore.

3. Estrategias de distribución

Tener el artefacto .nupkg es solo el primer paso. La decisión crítica es dónde debe alojarse.

Para publicar, necesitamos registrar los destinos en nuestro NuGet.config. Este archivo actúa como una "libreta de direcciones" bidireccional: sirve tanto para descargar (restore) como para subir (push).

<configuration>
  <packageSources>
    <clear />

    <!-- Estrategia A: Cloud (GitHub, Azure, AWS) -->
    <add key="github" value="https://nuget.pkg.github.com/TU_ORG/index.json" />

    <!-- Estrategia B: Server NuGet Privado -->
    <add key="baget" value="http://nuget-server:5555/v3/index.json" />

    <!-- Estrategia C: Pública -->
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />

    <!-- Estrategia D: On-Premise con carpetas compartidas -->
    <add key="shared" value="\\ServidorWindows\Nugets" />
  </packageSources>
</configuration>

Aquí están las estrategias ordenadas por madurez empresarial:

Estrategia A: Cloud Providers

El estándar de oro, el código fuente vive junto a sus artefactos. Proveedores como GitHub Packages, Azure Artifacts o AWS CodeArtifacts permiten que tus paquetes sean públicos o privados, seguros y accesibles solo mediante autenticación.

La ventaja clave es la integración con CI/CD: un Pipeline ejecuta los tests y, si pasan, publica automáticamente la nueva versión.

# Publicar usando el alias "github" definido en el config
dotnet nuget push "./nupkg/MyCompany.Common.1.0.0.nupkg" --source "github" --api-key TU_TOKEN

Estrategia B: Server NuGet Privado

La evolución moderna para redes aisladas, levantar un servidor web dedicado como BaGet.

Esto ofrece indexado rápido, caché, interfaz web para buscar paquetes y compatibilidad con clientes que no son Windows.

# Publicar usando el alias "baget" definido en el config
dotnet nuget push "./nupkg/MyCompany.Common.1.0.0.nupkg" --source "baget" --api-key TU_API_KEY

Estrategia C: NuGet.org

Si tu librería resuelve un problema universal y no contiene lógica de negocio propietaria, el destino es nuget.org. Es el repositorio central del ecosistema .NET. Tu código será accesible globalmente.

dotnet nuget push "./nupkg/MyCompany.Common.1.0.0.nupkg" --source "nuget.org" --api-key TU_NUGET_API_KEY

Estrategia D: On-Premise con carpetas compartidas

La estrategia clásica "Old School" en entornos corporativos Windows. Antes de Docker y la Nube, simplemente creábamos una carpeta en un File Server (\\192.168.1.50\Librerias) y apuntábamos Visual Studio allí.

# Publicar usando el alias "shared" definido en el config
dotnet nuget push "./nupkg/MyCompany.Common.1.0.0.nupkg" --source "shared"

Conclusión

La madurez en el desarrollo .NET implica moverse de la duplicación a la modularización.

Usa libraries bien etiquetadas (PackageTags) y licenciadas (PackageLicenseExpression) para centralizar la lógica.
Usa Tools para distribuir utilidades que mejoren la experiencia de desarrollo (DX).
Elige la estrategia de distribución que se alinee con tu infraestructura (Nube vs On-Premise).

Empaquetar tu código es una excelente forma de escalar tu impacto como desarrollador.

¡Happy coding! 🚀

Domina el uso de paquetes NuGet en .NET

Manuel Dávila Alarcón — Mon, 15 Dec 2025 11:07:29 +0000

¿Alguna vez has entrado a un proyecto Legacy (o incluso uno nuevo mal configurado), intentas compilar y tu consola se tiñe de rojo con errores tipo The type or namespace name 'X' could not be found? 😵 O peor aún, ¿te ha tocado ese escenario donde el proyecto busca una DLL en una carpeta de red Z:\Librerias que solo existía en la máquina del desarrollador que renunció hace dos años?

Si te ha pasado, sabes la frustración de perder horas (o días) solo intentando levantar el entorno. A menudo, el problema no es el código C#, es la gestión de dependencias. Hoy vamos a arreglar esto de raíz, entendiendo cómo consumir librerías de forma profesional, segura y escalable.

¿Qué es realmente NuGet?

Imagina que NuGet es el Amazon o Mercado Libre de .NET. Tú no fabricas cada tornillo de tu mueble; los pides a la tienda.

El Package: Es el producto que compras (Newtonsoft.Json, EntityFramework).
El Source (Feed): Es el almacén o la tienda donde se guardan los paquetes.

¿A dónde van mis paquetes?

Muchos desarrolladores creen que cuando ejecutan dotnet restore, las DLLs "mágicamente" aparecen en su proyecto. Entender el flujo real es vital para saber qué está pasando por detrás:

Request: Tu proyecto (.csproj) pide Newtonsoft.Json v13.0.1.
Restore: NuGet busca en los Sources configurados.
Global Packages Folder: Aquí está el secreto. NuGet descarga y descomprime el paquete en una carpeta global de tu usuario (generalmente %userprofile%\.nuget\packages en Windows o ~/.nuget/packages en Linux/Mac). No se guardan dentro de tu proyecto.
Build: Cuando compilas, .NET lee las DLLs de esa carpeta global y las copia a tu carpeta bin/Debug o bin/Release.

¿Por qué importa esto? Porque optimiza el espacio. Si tienes 10 proyectos usando la misma librería, solo se descarga una vez en tu disco duro.

La jerarquía de configuración

Antes de escribir una sola línea de configuración, debes entender cómo "piensa" NuGet. Cuando ejecutas un restore, no solo mira tu proyecto. NuGet combina configuraciones en cascada siguiendo una jerarquía estricta:

Nivel Máquina: A menudo este archivo ni siquiera existe físicamente o está vacío, a menos que un administrador de sistemas lo haya puesto ahí.
Nivel Usuario: Este es el más común (%appdata%\NuGet\NuGet.Config) y suele acumular mucha "basura digital" con el tiempo.
Nivel Directorio (Recursivo): ¡Aquí está la trampa! NuGet busca en la carpeta de tu solución... pero si no encuentra lo que busca, sube a la carpeta padre, y luego a la del abuelo, hasta llegar a la raíz del disco.

El origen del "En mi máquina funciona" 🤷‍♂️

Aquí nace el famoso meme. Imagina que tú tienes configurado un feed privado en tu Nivel Usuario porque trabajas en varios proyectos de la empresa. Creas un proyecto nuevo y compila perfecto. Tu compañero clona el repositorio, intenta compilar y... error.

¿Por qué? Porque tu proyecto está dependiendo de una configuración "invisible" que vive solo en tu usuario. Para tu compañero, ese feed no existe.

¿Cómo detecto esto? No adivines. Sitúate en la carpeta de tu solución y ejecuta el siguiente comando:

dotnet nuget list source

Este comando te mostrará la lista final y combinada de todos los orígenes que NuGet está usando realmente en esa carpeta. Si ves rutas que no reconoces o servidores apagados, es culpa de la herencia.

NuGet.config

¿Cómo rompemos esa cadena de herencia tóxica y arreglamos el proyecto para todos? Creando un archivo NuGet.config explícito en la raíz de tu solución.

Aquí tienes una configuración que cubre los escenarios reales:

<configuration>
  <packageSources>
    <!-- ¡IMPORTANTE! <clear/> elimina toda la "basura" heredada del usuario o máquina -->
    <clear />

    <!-- 1. El estándar público -->
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />

    <!-- 2. Nube Privada (GitHub Packages, Azure, AWS) -->
    <!-- Ideal para equipos modernos y CI/CD -->
    <add key="GitHubFeed" value="https://nuget.pkg.github.com/mi-empresa/index.json" />

    <!-- 3. Servidor NuGet Local (BaGet o similar) -->
    <add key="BadGetFeed" value="http://servidor-interno:5555/v3/index.json" />

    <!-- 4. Carpeta Local en Servidor On-Premise -->
    <add key="OnPremiseFeed" value="./LibreriasAntiguas" />
  </packageSources>

  <!-- Puedes deshabilitar fuentes temporalmente sin borrar la línea -->
  <disabledPackageSources>
     <add key="OnPremiseFeed" value="true" />
  </disabledPackageSources>

  <packageSourceCredentials>
    <!-- Autenticación Segura para feeds privados (Usa variables de entorno) -->
    <GitHubFeed>
        <add key="Username" value="DevUser" />
        <add key="ClearTextPassword" value="%GITHUB_TOKEN%" />
    </GitHubFeed>
  </packageSourceCredentials>
</configuration>

Beneficios de configurar esto:

🛡 Aislamiento: Con <clear />, proteges tu proyecto de configuraciones globales rotas.
🛠 Independencia: Si un dev nuevo entra, solo hace git clone y dotnet restore. No necesita configurar nada manual.
🔄 CI/CD Friendly: Tus Pipelines sabrán exactamente dónde buscar sin pasos extraños.

El caos de la prioridad

Aquí es donde muchos desarrolladores fallan. Si tienes configurado nuget.org y GitHubFeed, y ambos tienen un package llamado Newtonsoft.Json... ¿cuál se descarga?

NuGet actua "al primero que responda". Esto es peligroso por dos razones:

Rendimiento: NuGet pierde tiempo buscando tu package privado en la tienda pública.
Seguridad: Si un atacante sube un paquete malicioso a nuget.org con el mismo nombre que tu paquete privado interno (ej: MiBanco.Core), ¡tu proyecto podría descargar el package del atacante sin darte cuenta! 🚨

Para solucionar el caos de prioridad y asegurar qué bajamos, tenemos dos herramientas clave:

1. Package Source Mapping

Es básicamente decirle a NuGet: "Los paquetes de Microsoft búscalos en la tienda pública, y los paquetes de mi empresa SOLO búscalos en mis servidores".

<configuration>
  <!-- ... sección packageSources definida arriba ... -->

  <!-- AQUÍ ESTÁ LA MAGIA -->
  <packageSourceMapping>

    <!-- Regla 1: Mis librerías Core van a GitHub Packages -->
    <packageSource key="GitHubFeed">
      <package pattern="MyCompany.Core.*" />
      <package pattern="MyCompany.Auth.*" />
    </packageSource>

    <!-- Regla 2: Librerías internas van al Server NuGet Privado -->
    <packageSource key="BadGetFeed">
      <package pattern="InternalTools.*" />
    </packageSource>

    <!-- Regla 3: Componentes viejos van a la carpeta local -->
    <packageSource key="OnPremiseFeed">
       <package pattern="OldComponent.WinForms.*" />
    </packageSource>

    <!-- Regla 4: Todo lo demás (Microsoft, System, etc.), búscalo en nuget.org -->
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>

  </packageSourceMapping>
</configuration>

2. Auditoría de vulnerabilidades

A veces descargas el paquete correcto, pero tiene agujeros de seguridad conocidos. No necesitas herramientas caras; .NET lo trae nativo.
Ejecuta esto regularmente o en tu CI/CD:

dotnet list package --vulnerable

Te dirá qué paquetes tienen riesgos (Crítico, alto o moderado) y a qué versión segura actualizar.

Central Package Management (CPM)

Si trabajas en una solución con muchos servicios, seguro te ha pasado esto:

El Proyecto A usa Newtonsoft.Json v11.
El Proyecto B usa Newtonsoft.Json v13.
El Proyecto C usa Newtonsoft.Json v9.

¡Es un caos de versiones! 🤯

Para solucionar esto en proyectos modernos, usamos Central Package Management (CPM). En lugar de definir la versión en cada .csproj, las centralizamos.

Paso 1: Crear archivo Directory.Packages.props en la raíz

<Project>
  <PropertyGroup>
    <!-- Activar CPM -->
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <!-- Aquí defines la versión UNA SOLA VEZ para toda la solución -->
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
    <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />
  </ItemGroup>
</Project>

Paso 2: Limpiar tus .csproj

En tus proyectos individuales, ya no pones la versión, solo el nombre:

<!-- En .csproj -->
<ItemGroup>
  <!-- Sin versión porque ya lo toma de Directory.Packages.props -->
  <PackageReference Include="Newtonsoft.Json" />
</ItemGroup>

¿Cómo aplico los cambios?

Una vez que has creado o ajustado tu archivo NuGet.config con los sources y el mapping, ve a tu terminal y ejecuta:

# Limpia cachés locales para asegurar que las reglas nuevas apliquen
dotnet nuget locals all --clear

# Restaura usando la nueva configuración
dotnet restore

¿Por qué deberías dominar esto?

Resurrección de Proyectos: Puedes levantar proyectos Legacy en minutos mapeando los source que corresponde.
Seguridad Empresarial: Proteges a tu organización de ataques de cadena de suministro y vulnerabilidades conocidas.
Arquitectura Limpia: Con CPM, mantienes tus dependencias ordenadas y actualizadas sin esfuerzo.

No dejes que las dependencias te controlen a ti. ¡Toma el control de tus paquetes!

¡Happy coding! 🚀

Git Merge vs Git Rebase: Cómo tener un historial ordenado y claro

Manuel Dávila Alarcón — Fri, 07 Feb 2025 05:51:39 +0000

Si trabajas en equipo con Git, seguramente has escuchado sobre git merge y git rebase. Ambos sirven para combinar ramas, pero tienen efectos diferentes en la historia del repositorio. Usarlos correctamente puede hacer que tu historial de Git sea fácil de entender 🤩 o un desastre incomprensible 😵.

Vamos a ver en detalle en qué se diferencian y cuándo usar cada uno.

Git Merge

📌 ¿Qué hace Git Merge y por qué es útil??

Cuando usas git merge, Git toma dos ramas y las combina en una nueva confirmación (commit), manteniendo el historial de ambas ramas intacto. Se usa mucho cuando integras una rama secundaria en la principal (como develop o main).

Imagina que tienes dos caminos separados que finalmente se juntan en una carretera principal. Sigues viendo de dónde viene cada uno, pero ahora forman parte de la misma ruta.

🛠️ Cómo usar Git Merge y cómo se ve en los gráficos

Para aplicar merge a una rama llamada develop, es decir queremos enviar los cambios de feature/chatbot hacia develop. Primero debes posicionarte en la rama develop y ejecutar el siguiente comando:

git checkout develop
git merge feature/chatbot

Esto genera un commit de merge en develop con todo el historial de feature/chatbot.

Cómo debería verse un merge en el gráfico de historial de git.

Como puedes ver, hay una evidencia clara de que el branch feature/chatbot se incorporó en develop, lo hace muy fácil de leer.

En este caso no hubo conflictos. Sin embargo, sabemos que en un entorno productivo, el caos predomina 🔥, así que veamos un escenario más conflictivo.

🔍 Caso real: Cuándo usar Git Merge

Imagina que trabajas en un equipo desarrollando una nueva funcionalidad en una rama llamada feature/chatbot. Mientras tanto, otros compañeros han seguido trabajando en develop, agregando nuevas mejoras y correcciones de errores.

Llega el momento de integrar feature/chatbot en develop, pero quieres asegurarte de que el historial refleje claramente que esta funcionalidad se desarrolló en paralelo y luego se unió a la rama principal. Aquí es donde git merge brilla.

Se creará un commit de merge que preservará todo el historial de feature/chatbot, dejando claro cuándo y cómo se unieron los cambios. Esto es útil en proyectos colaborativos porque facilita el rastreo de la evolución del código y evita sobrescribir accidentalmente cambios de otros.

Sin embargo, dado que develop ha seguido evolucionando con cambios que no están en feature/chatbot, es probable que debas resolver conflictos de merge. Esto sucede porque algunos archivos pueden haber sido modificados en ambas ramas, y Git no sabe cuál versión debería mantenerse.

La solución consiste en revisar y seleccionar manualmente los cambios adecuados antes de finalizar el merge.

Una vez que solucionas los conflictos entre 2 ramas, el mismo conflicto no debería volver a aparecer (a menos que haya nuevas modificaciones en el archivo o clase que otro desarrollador ha modificado). Incluso si agregas un nuevo commit a feature/chatbot y vuelves aplicar merger hacia develop nuevamente.

Si en lugar de git merge intentáramos un git rebase, estaríamos reescribiendo la historia de feature/chatbot como si siempre hubiera estado basada en la última versión de develop. Esto podría generar problemas si otros colaboradores ya han trabajado sobre la misma rama y necesitan un historial claro de integración.

Por eso, git merge es la mejor opción aquí, ya que mantiene un historial fiel del desarrollo de la funcionalidad y facilita la colaboración en equipo.

Para los ejemplos del gráfico del historial de Git utilizo GitKraken Desktop, pero en cualquier cliente de Git deberías poder visualizarlo.

Git Rebase

📌 ¿Qué hace Git Rebase y por qué es útil??

git rebase toma los commits de una rama y los aplica sobre otra como si siempre hubieran estado allí. En lugar de mezclar con un commit de merge, reescribe la historia para que los cambios parezcan hechos directamente sobre la rama principal.

Es como si, en lugar de recordar que tomaste un desvío en el camino, tu GPS reescribiera el trayecto para que pareciera que nunca te desviaste.

También se podría usar para no dejar evidencia de cambios que vienen de una rama específica 👀 aparecen los commits pero no la rama del que vienen.

🛠️ Cómo usar Git Rebase y cómo se ve en los gráficos?

Para aplicar rebase a una rama llamada feature/oauth-gmail, la cual se creó anteriormente a partir de main. Primero debes posicionarte sobre la rama feature/oauth-gmail y ejecutar el siguiente comando:

git checkout feature/oauth-gmail
git rebase main

También podrías hacerlo desde un cliente de Git como Fork, Git Kraken u otro, presionando clic derecho a la rama que quieres aplicar rebase (como main) y seleccionar "rebase".

Esto generará que la rama feature/oauth-gmail se alinee con la rama main como si se hubiera creado con la ultima versión de main.

Cómo debería verse un rebase en el gráfico de historial de git.

🔍 Caso real: Cuándo usar Git Rebase

Imagina que estás trabajando en una nueva funcionalidad en una rama feature/oauth-gmail, la cual creaste a partir de master. Mientras tanto, master ha recibido múltiples actualizaciones, incluyendo hotfixes y nuevos releases.

Dado que feature/oauth-gmail proviene de master, lo ideal es hacer un git rebase master para alinear la rama con los cambios más recientes sin introducir un commit de merge innecesario.

Si en su lugar usaras git merge, se generaría una mezcla bidireccional entre master y feature/oauth-gmail, lo que haría más confusa la lectura del historial y rompería con la estrategia de branching.

Veamos como quedaría si queremos integrar con merge y luego queremos hacer un commit.

Como puedes ver, la rama master deja de tener un historial limpio 😖

Con git rebase master, los commits de feature/oauth-gmail se reordenan y aplican sobre la última versión de master, manteniendo un historial más limpio y lineal. Esto facilita la revisión del código y evita la complejidad innecesaria en el historial del proyecto.

Si hay conflictos, deberás resolverlos manualmente en cada paso del rebase, pero al final obtendrás una estructura más clara y organizada.

Incluso si quisiéramos hacer un nuevo commit quedaría más limpio tanto el historial de commits del feature como master.

Tanto con Git Merge como Git Rebase, no te salvarás de solucionar conflictos de merge. El propósito de estos comandos es mantener un historial de git de la forma más óptima para los desarrolladores y no tiene que ver con la forma de manejar los conflictos de merge.

🎉 Conclusión

Usa merge para integrar ramas de larga duración (como features hacia develop en Git Flow). Usa rebase para mantener actualizadas tus feature branches antes de mergearlas.

Tanto git merge como git rebase son herramientas poderosas y necesarias. No hay una "mejor" que otra, sino que cada una se adapta a diferentes situaciones. Si quieres un historial claro y ordenado, usa rebase. Si necesitas contexto y claridad en las integraciones, opta por merge.
Es importante que todo el equipo siga las mismas prácticas para mantener un historial de Git consistente.

¡Ahora sí, a escribir código y a hacer commits con confianza! 🚀

Cómo gestionar tus proyectos de software con Github

Manuel Dávila Alarcón — Wed, 15 Jan 2025 14:54:16 +0000

¿Estás comenzando un proyecto de software y no sabes dónde gestionarlo? Hoy quiero contarte por qué GitHub puede ser tu mejor aliado. Aunque existen herramientas increíbles como GitLab o Bitbucket para repositorios de código, Jira o Trello para tareas, y Confluence o Notion para documentar, GitHub te ofrece un combo completo.

En este artículo, exploraremos cómo aprovechar GitHub al máximo, desde la gestión de tareas hasta la automatización de procesos. Si buscas una solución integral para gestionar tus proyectos de software, ¡estás en el lugar correcto! 😉

¿Qué es GitHub y qué lo hace especial?

GitHub es mucho más que una plataforma para almacenar código. Es un ecosistema donde puedes controlar versiones, colaborar con equipos, gestionar tareas y mucho más. Pero antes de avanzar, aclaremos algo fundamental:
¿Git o GitHub?
👁️‍🗨️ Aunque suenen similares, son diferentes.

Git: Es un sistema de control de versiones que permite rastrear cambios en tu código.
GitHub: Es una plataforma basada en la nube que utiliza Git para facilitar el trabajo colaborativo.

Si no estás familiarizado con Git, te recomiendo la la ruta de aprendizaje de Git en Microsoft Learn

¿Por qué usar GitHub?

GitHub no se limita a almacenar código; ofrece herramientas avanzadas que te permiten gestionar proyectos de principio a fin. Algunas de sus funcionalidades clave incluyen:
✔️Issues: Una forma estructurada de registrar problemas, tareas o ideas.
✔️Pull Request: Para colaborar en el código, revisarlo y discutir cambios antes de integrarlos.
✔️Colaboradores y equipos: Gestiona quién tiene acceso a tu proyecto y qué permisos tienen.
✔️Github Projects: Tableros tipo Kanban u otro tipo de plantilla para organizar tareas y planificar proyectos.
✔️Github Wiki: Documentación centralizada para tu equipo.
✔️Github Copilot: Tu asistente de IA Generativa para escribir código más rápido.
✔️Github Actions: Automatiza procesos como pruebas, despliegues y mucho más.
✔️Github Codespaces: Entornos de desarrollo en la nube.
✔️Github Pages: Hospeda sitios web estáticos directamente desde tu repositorio.
✔️Code Security: Herramientas para proteger tu código.
✔️Marketplace: Encuentra extensiones que potencien tu flujo de trabajo.

Caso práctico: Gestión de un proyecto de red social

Imagina que estás desarrollando una red social en .NET con un equipo. Cada persona está encargada de una funcionalidad: autenticación, perfiles de usuario, publicaciones y notificaciones. A continuación, te muestro cómo usar GitHub en cada etapa del proyecto.

1. Crear el repositorio base

Lo primero es crear un repositorio para centralizar todo tu código y configurarlo.

Pasos básicos:

Inicia sesión en GitHub.
Haz clic en "New Repository".
Completa los campos (nombre del repositorio, descripción, visibilidad).
Agrega un .gitignore y una licencia, si es necesario.

2. Agregar colaboradores y equipos 👨‍💻👩‍💻

Agregar colaboradores en GitHub es como organizar una fiesta: tú eres el anfitrión, y los colaboradores son los invitados que pueden ayudar a decorar, traer comida (o en este caso, código).

Puedes agregar a cada miembro del equipo con permisos específicos. Por ejemplo, el líder del proyecto podría tener permisos de administrador, mientras que los desarrolladores solo pueden enviar código y revisarlo.

Pasos para agregar un colaborador:

Ve a la página principal de tu repositorio en GitHub.
Haz clic en la pestaña "Settings" (configuración).
Busca la sección "Collaborators and Teams" y haz clic.
En "Add Collaborator", escribe el nombre de usuario o correo electrónico de la persona.
La persona recibirá una invitación y, al aceptarla, ya será parte del proyecto.

Si tu proyecto es Open Source, puedes recibir contribuciones mediante pull request de terceros sin tener que agregarlos como colaborador.

3. Organizar tareas con Issues y Projects

Projects: Usa un tablero tipo Kanban con columnas como "Por hacer", "En progreso" y "Completado" para mover tareas según su estado.
Issues: Define tareas como "Agregar autenticación con OAuth2" o "Implementar Endpoint Publicaciones". Cada issue tiene un responsable, una prioridad y una fecha límite.

4. Crear, revisar y aprobar cambios con Pull Requests 🔎

Cuando alguien del equipo desarrolla una funcionalidad, como "Publicaciones", crea una rama (feature/posts) y abre un Pull Request (PR) para que el resto del equipo revise el código.

Los revisores pueden comentar, sugerir cambios, y asegurarse de que todo esté en orden antes de integrar el código.

Si todo esta bien, podemos aprobar el cambio e integrarlo a rama que solicitaron en el pull request.

5. Documentar con GitHub Wiki 📝

La documentación es clave para evitar confusiones. En GitHub Wiki puedes incluir:

Arquitectura del sistema: Cómo se conecta cada módulo.
Guía de instalación: Instrucciones para configurar el entorno.
Dependencias: Herramientas y librerías utilizadas.

Es probable que hacer la documentación te cause aburrimiento pero no tenerlo te causará pesadillas. 😖

6. Acelerar el desarrollo con GitHub Copilot 🤖

Escribir código repetitivo puede ser frustrante. Con GitHub Copilot, puedes generar lógica automáticamente. Por ejemplo, al implementar notificaciones, Copilot puede sugerir código para manejar excepciones o enviar correos.

GitHub Copilot ahora tiene un plan gratuito que puedes usar desde editores como Visual Studio Code, Visual Studio o JetBrains. Más detalles aquí.

7. Automatizar con GitHub Actions ⚙️

GitHub Actions permite automatizar flujos de trabajo. Algunos ejemplos:

Ejecutar pruebas unitarias al crear un PR.
Desplegar la aplicación en Azure tras pasar las pruebas.
Enviar notificaciones de estado al equipo vía Slack.

8. Trabajar desde cualquier lugar con Github Codespaces 🖥️

¿Necesitas trabajar desde un dispositivo donde no tienes configurado el entorno? GitHub Codespaces te ofrece un entorno de desarrollo virtual listo para usar desde tu navegador.

En caso de que alguien del equipo necesite contribuir rápidamente pero no tiene el entorno configurado, puede abrir un Codespace.

Recuerda detener o eliminar tu codespace para evitar consumo innecesario de recursos, ya que hay un límite mensual que pueden utilizar gratuitamente. Puedes ver tu consumo de recursos aquí.

9. Publicar documentación o prototipos con Github Pages

Cuando tu proyecto esté listo o necesites compartir documentación o prototipos con clientes, GitHub Pages es una solución ideal para alojar sitios web estáticos. Puedes usarlo para:

Documentación del proyecto: Crear una página atractiva para tu Wiki con Markdown o un generador como Jekyll.
Demostraciones de prototipos: Publicar una versión básica de tu red social para que los stakeholders puedan visualizarla.

Supongamos que has creado una versión mínima de tu red social con una interfaz básica. Podrías usar GitHub Pages para desplegar esta demo. Solo necesitas guardar los archivos HTML, CSS y JavaScript y habilitar la opción en la configuración del repositorio.

Con Github Pages incluso podrías personalizar con un dominio propio como www.example.com.

10. Proteger tu código con GitHub Code Security 🔒

GitHub ofrece herramientas integradas para mantener tu proyecto seguro y evitar vulnerabilidades. Algunas de las funciones más destacadas son:

Escaneo de código: Analiza tu repositorio en busca de vulnerabilidades en librerías o errores de seguridad en tu código.
Dependabot Alerts: Detecta dependencias obsoletas o con problemas y sugiere actualizaciones automáticas.
Protección de ramas: Configura restricciones en la rama principal para evitar que se integre código sin revisión.

Es probable que algunas funciones no esten habilitadas para repositorios privados o de organizaciones.

11. Aprovecha Github Marketplace 🛒

GitHub Marketplace es un repositorio de herramientas y aplicaciones que puedes integrar fácilmente a tu proyecto. Desde CI/CD hasta análisis de código, modelos de IA y extensiones para Copilot, y bots para gestionar tareas, tienes múltiples opciones para mejorar tu productividad.

Por ejemplo, puedes instalar un Action para desplegar automáticamente tu aplicación en Docker Hub.

Herramientas adicionales de Marketplace que puedes explorar:

ZenHub: Para extender la funcionalidad de Projects con diagramas de Gantt.
Snyk: Para análisis avanzado de vulnerabilidades.
CodeClimate: Para medir la calidad del código.

Dedica tiempo a explorar Marketplace, ya que muchas de estas herramientas son gratuitas o tienen planes básicos perfectos para empezar.

Beneficios de usar GitHub para tus proyectos

Centralización: Todo (código, tareas, documentación) en un solo lugar.
Colaboración: Facilita el trabajo en equipo con herramientas intuitivas.
Escalabilidad: Desde proyectos pequeños hasta sistemas empresariales complejos.
Automatización: Ahorras tiempo en tareas repetitivas.
Flexibilidad: Adapta las herramientas a tus necesidades.

¡Atrévete a explorar GitHub!

GitHub no es solo para almacenar código; es una herramienta integral que puede transformar cómo gestionas tus proyectos. Si estás buscando optimizar tu flujo de trabajo y trabajar de manera más eficiente, empieza hoy mismo.

GitHub tiene una gran comunidad y puedes encontrar recursos de aprendizaje, participar en proyectos Open Source o integrar GitHub con tus propias aplicaciones usando su API.

¡Manos a la obra! Crea tu primer repositorio y experimenta todo lo que GitHub tiene para ofrecer. Si tienes preguntas o necesitas ayuda, no dudes en dejar un comentario o compartir este artículo con alguien que pueda beneficiarse.

Guía para Iniciarse en la Programación Funcional con C#

Manuel Dávila Alarcón — Thu, 01 Aug 2024 15:26:45 +0000

¿Alguna vez te has visto lidiando con funciones repetitivas y complicadas en tu código? La Programación Funcional puede ayudarte a simplificar esos problemas. Por ejemplo, las expresiones lambda y las funciones anónimas permiten escribir código más limpio y directo, haciendo que tareas que antes eran engorrosas se vuelvan mucho más manejables.

Este paradigma de programación ofrece una forma diferente de pensar y escribir código, centrándose en funciones puras, inmutabilidad, y minimización de efectos secundarios. En este artículo, exploraremos los fundamentos de la programación funcional en C#, sus beneficios, y cómo puedes empezar a aplicarlos en tus proyectos.

A menudo, la programación funcional se asocia con lenguajes como Haskell o Scala, pero C# también ofrece un soporte robusto para este estilo de programación. Incluso si vienes de un fondo de programación orientada a objetos, estos conceptos pueden enriquecer tu enfoque y mejorar la calidad de tu código.

¿Qué es la Programación Funcional?

La Programación Funcional es un paradigma de programación que evita cambiar el estado y los datos mutables. A diferencia de la programación orientada a objetos, que se centra en objetos y su interacción, la programación funcional se enfoca en la aplicación de funciones, lo que resulta en un código más predecible y fácil de razonar.

En términos simples, se trata de construir software al componer funciones puras, que son funciones sin efectos secundarios y que siempre producen el mismo resultado dado el mismo conjunto de parámetros. Esto permite crear sistemas más modulares y testables.

Algunos beneficios de la Programación Funcional:

Al reducir la complejidad del estado mutable y el comportamiento implícito, el código se vuelve más fácil de leer y mantener.
Las funciones puras, al no depender de un estado externo, son más fáciles de probar, ya que siempre producirán el mismo resultado con los mismos parámetros.
Al evitar el estado mutable, la programación funcional facilita el desarrollo de aplicaciones concurrentes, donde múltiples procesos pueden ejecutarse simultáneamente sin riesgo de colisión de datos.

Cuando utilizas un paradigma de programación, no estas atado a usar sólo este, puedes hacer una combinación de diferentes paradigmas de ser necesario. C# es un lenguaje orientado a objetos, así que al usar el paradigma Funcional, ya estas combinando estos 2 paradigmas.

Características de la Programación Funcional

Estado compartido 🔗

En la programación funcional, la idea es evitar o minimizar el estado compartido. ¿Qué significa esto? Básicamente, que las funciones no dependen de variables globales que puedan ser cambiadas por otras partes del programa. En vez de andar modificando cosas por todos lados, las funciones toman datos y devuelven nuevos datos, sin cambiar los originales.

Al reducir el estado compartido, se bajan los problemas relacionados con la concurrencia, que es cuando varias cosas intentan cambiar datos al mismo tiempo y causan errores.

Inmutabilidad 🔒

La inmutabilidad es como una regla de oro en la programación funcional. Significa que una vez que se crea un dato, no se cambia. En lugar de modificar un objeto o una variable, lo que hacemos es crear uno nuevo con los cambios que queramos. Aunque al principio pueda parecer menos eficiente, esto hace que el código sea más seguro y predecible.

Por ejemplo, imagina que tienes un carrito de compras y querés agregar un producto, en vez de cambiar el carrito que ya tienes, creas uno nuevo que incluye el producto extra. Así, el carrito original no se toca y evitás problemas si otras partes del código lo están usando.

Efectos Secundarios ⚠️

Los efectos secundarios ocurren cuando una función, además de devolver un valor, cambia algo en el estado del programa o interactúa con el exterior (como escribir en un archivo, actualizar una base de datos o llamadas a una API). En la programación funcional, la idea es minimizar estos efectos para que el código sea más fácil de entender y no cause sorpresas.

Delegados en `C#`

Antes de entrar en más conceptos de la programación Funcional, hablemos un poco de C# y algunas palabras reservadas que te serviran más adelante.

Un delegado es un tipo que representa una referencia a un método. En C#, los delegados se utilizan para definir tipos de métodos que pueden ser asignados a variables, pasados como argumentos a otros métodos, o utilizados como callbacks

public delegate int Operacion(int x, int y);

public class EjemploDelegado
{
    public static int Sumar(int a, int b) => a + b;

    public static void Main()
    {
        Operacion operacion = Sumar;
        Console.WriteLine(operacion(5, 3)); // 8
    }
}

Func

Func es un delegado genérico que encapsula un método que puede devolver un valor. Se puede usar para representar funciones con hasta 16 parámetros. El último tipo genérico en Func siempre representa el tipo de retorno.

Func<int, int, int> suma = (x, y) => x + y;

Aquí, suma es una instancia de Func que representa una función que toma dos enteros como parámetros y devuelve un entero.

Esto es muy similar a crear un método con un tipo de dato de retorno:

public int suma(int x, int y) 
{ 
    return x + y 
}

Action

Action es otro delegado genérico, similar a Func, pero se usa para métodos que no devuelven un valor (es decir, devuelven void). Action puede tener hasta 16 parámetros de entrada.

Action<string> imprimir = mensaje => Console.WriteLine(mensaje);

En este caso, imprimir es una instancia de Action que representa un método que toma una cadena como argumento y no devuelve ningún valor.

Esto es muy similar a crear un método de tipo void:

public void imprimir(string mensaje) 
{ 
    Console.WriteLine(mensaje); 
}

Predicate

Un Predicate es un delegado que encapsula un método que toma un argumento de tipo T y devuelve un bool. Este delegado se usa frecuentemente en métodos de colecciones genéricas, como List, para encontrar o filtrar elementos que cumplan con ciertos criterios.

Predicate<int> esPar = num => num % 2 == 0;

En este ejemplo, esPar es un Predicate que representa una función para determinar si un número es par.

Esto es muy similar a crear un método que retorne un tipo bool:

public bool esPar(int num) {
    return num % 2 == 0;
}

¡Ahora sí! Retomemos los conceptos de la Programación Funcional utilizando los delegados aprendidos.

Funciones Puras

Las funciones puras son aquellas que siempre devuelven el mismo resultado cuando se les da el mismo input y no causan efectos secundarios. Esto significa que no cambian el estado de nada fuera de ellas ni dependen de algo que pueda cambiar fuera de su ámbito.

Imagina que tienes una función que calcula el precio final de un producto aplicando un descuento:

decimal CalcularPrecioFinal(decimal precioBase, decimal descuento)
{
    return precioBase - (precioBase * descuento);
}

Esta función es pura porque siempre devolverá el mismo resultado si se le pasa el mismo precioBase y descuento, y no cambia nada más en el sistema.

Como no existe una lógica compleja, podemos refactorizar utilizando un delegado.

Func<decimal, decimal, decimal> CalcularPrecioFinal = (precioBase, descuento) => precioBase - (precioBase * descuento);

Expresiones Lambda y Funciones Anónimas

Las expresiones lambda y las funciones anónimas son formas de definir funciones rápidas y temporales, sin necesidad de nombrarlas explícitamente. Son muy útiles para operaciones sencillas o para pasar funciones como parámetros.

En el ejemplo anterior "(precioBase, descuento) => precioBase - (precioBase * descuento)" era nuestra expresión lambda.

Probemos con otro ejemplo, supongamos que tienes una lista de productos y quieres obtener sólo los nombres de los productos en oferta:

var nombresProductosEnOferta = productos
    .Where(producto => producto.EsEnOferta)
    .Select(producto => producto.Nombre)
    .ToList();

Aquí, producto => producto.EsEnOferta y producto => producto.Nombre son expresiones lambda que se usan para filtrar y proyectar los productos de la lista.

Composicion de Funciones

La composición de funciones es la práctica de combinar funciones pequeñas y simples para construir funciones más complejas. En programación funcional, es común crear funciones reutilizables que se pueden combinar de diversas maneras.

Puedes tener funciones separadas para calcular impuestos y descuentos, y luego componerlas para obtener el precio final:

Func<decimal, decimal> aplicarImpuesto = precio => precio * 1.18m;
Func<decimal, decimal> aplicarDescuento = precio => precio * 0.90m;

Func<decimal, decimal> calcularPrecioFinal = precio => aplicarDescuento(aplicarImpuesto(precio));

En este ejemplo, calcularPrecioFinal es una función compuesta que aplica primero el impuesto y luego el descuento al precio de un producto.

Funciones de Orden Superior

Las funciones de orden superior son aquellas que pueden tomar otras funciones como argumentos o devolverlas como resultados. Esto es útil para crear funciones más generales y reutilizables.

Si quieres filtrar productos según diferentes criterios (por ejemplo, productos en oferta o productos baratos), puedes usar una función de orden superior:

List<Product> FiltrarProductos(List<Product> productos, Predicate<Product> criterio)
{
    return productos.FindAll(criterio);
}

var productosEnOferta = FiltrarProductos(productos, producto => producto.EsEnOferta);
var productosEconomicos = FiltrarProductos(productos, producto => producto.Precio < 50.0m);

En este caso, FiltrarProductos es una función de orden superior que recibe un predicado (criterio) para filtrar productos.

Usar un enfoque funcional puede mejorar la mantenibilidad y escalabilidad de tus proyectos. Esto es especialmente útil en sistemas grandes o de larga vida, donde el código limpio y modular es crucial.

Si eres nuevo en la programación funcional, comienza adoptando pequeñas prácticas en tus proyectos actuales. Utiliza expresiones lambda, funciones puras y trata de minimizar el estado mutable. Experimenta con delegados como Func, Action y Predicate para familiarizarte con su uso.

Además, considera el uso de herramientas y bibliotecas que faciliten la programación funcional en C#, como LINQ, que permite realizar consultas y manipulaciones de datos de manera funcional.

La programación funcional puede parecer un cambio radical si vienes de un fondo orientado a objetos, pero los beneficios en términos de claridad, mantenibilidad y testabilidad del código valen la pena. Espero que este contenido te haya sido de utilidad y te brinde un acercamiento a la programación funcional con C#.

!Happy coding! ✨

Explorando los Fundamentos de la Programación Orientada a Objetos en C#

Manuel Dávila Alarcón — Wed, 31 Jul 2024 01:47:25 +0000

¿Te has encontrado alguna vez con código tan desordenado que parece un rompecabezas imposible de resolver? En el mundo actual, donde dependemos de aplicaciones para casi todo, mantener el código organizado y eficiente es crucial. Aquí es donde entra en juego la Programación Orientada a Objetos (POO). Este paradigma nos ayuda a que nuestros proyectos sean más fáciles de entender, mantener y expandir.

Es cierto que incluso con POO, el código puede volverse desordenado, especialmente en sistemas legacy que han evolucionado sin una dirección clara. Sin embargo, al adoptar buenas prácticas de POO, podemos minimizar estos problemas.

En este artículo, vamos a desglosar los conceptos básicos de la POO en C#, explicando por qué es tan valiosa y cómo puedes usarla en tus propios proyectos.

¿Qué es la Programación Orientada a Objetos?

La Programación Orientada a Objetos (POO) es un paradigma de programación que utiliza "objetos" para representar cosas del mundo real. ¿Cómo funciona? Imagina que tienes una aplicación y quieres crear algo que represente un "Personaje" en un juego. Ese personaje puede tener atributos como salud y fuerza, y métodos para atacar o defenderse. Así, en lugar de escribir todo de una manera desordenada, puedes organizar tu código en objetos que son fáciles de manejar.

Probablemente, alguna vez te pasó que el código que hiciste hace una semana ya no lo recuerdas 😅, no lo podemos evitar pero podemos hacerlo más fácil de manejar con POO. Alguno de sus beneficios:

Organiza el código de una forma más entendible, haciendo que sea más fácil trabajar en equipo o volver al proyecto después de un tiempo.
Facilita la actualización y mejora del software, ya que puedes agregar nuevas funcionalidades sin romper todo lo que ya funciona.
Promueve buenas prácticas de programación como el encapsulamiento, la herencia y el polimorfismo, lo que se traduce en un código más limpio y reutilizable.

¡Ojo! La POO no es la solución mágica. Incluso con este enfoque, es posible que el código se vuelva un quilombo, sobre todo en sistemas antiguos o mal diseñados. Por eso, es clave seguir buenas prácticas y mantener el código lo más prolijo posible.

Entender bien los conceptos de la POO es fundamental para evitar los errores comunes y sacar el máximo provecho de este paradigma. No te olvides de practicar y de leer código de otros desarrolladores para ver cómo aplican estos conceptos en situaciones reales.

Clases y Objetos en `C#`

En la POO, las clases son como los planos o moldes para crear objetos. Imagina una clase como una receta de cocina que define qué ingredientes se necesitan y cómo combinarlos para hacer un plato. En nuestro caso, la "receta" es una clase, y los "platos" que creamos a partir de esa receta son los objetos.

Clase

Una clase en C# define un tipo de datos y especifica qué propiedades y métodos tendrá. Pensemos en un videojuego: tienes varios personajes, y cada uno tiene características y habilidades diferentes. Para manejar esto, podríamos crear una clase llamada Personaje que sirva como base para todos los personajes del juego, con propiedades como Nombre, Vida, Fuerza, y métodos como Atacar() y Defender().

public class Personaje
{
    public string Nombre { get; set; }
    public int Vida { get; set; }
    public int Fuerza { get; set; }

    public void Atacar()
    {
        Console.WriteLine($"{Nombre} ataca con una fuerza de {Fuerza}.");
    }

    public void Defender()
    {
        Console.WriteLine($"{Nombre} se defiende, reduciendo el daño.");
    }
}

Objetos

Un objeto es una instancia concreta de una clase. Imagina que la clase Personaje es el diseño de un personaje; un objeto sería un personaje específico dentro del juego, como un guerrero o un mago, cada uno con sus propios valores para Nombre, Vida, y Fuerza.

Personaje guerrero = new Personaje();
guerrero.Nombre = "Thorin";
guerrero.Vida = 150;
guerrero.Fuerza = 75;
guerrero.Atacar(); // Thorin ataca con una fuerza de 75.

En este ejemplo, guerrero es un objeto de la clase Personaje que representa a un personaje específico en el videojuego. Cada objeto puede tener valores diferentes para las mismas propiedades, permitiendo una gran flexibilidad y personalización en el juego.

Propiedades

Las propiedades en C# actúan como características del objeto para almacenar datos. Funcionan como variables, pero con un mayor control sobre cómo se asignan y recuperan los valores. En el caso del videojuego, las propiedades de la clase Personaje incluyen atributos como Nombre, Vida y Fuerza.

public class Personaje
{
    public string Nombre { get; set; }
    public int Vida { get; set; }
    public int Fuerza { get; set; }
}

Estas propiedades permiten acceder y modificar los atributos del personaje de manera controlada. Por ejemplo, si quieres ajustar la vida de un personaje cuando recibe daño, simplemente actualizás la propiedad Vida.

Métodos

Los métodos son funciones definidas dentro de una clase que permiten la comunicación entre objetos. En nuestro videojuego, los métodos Atacar() y Defender() definen cómo los personajes interactúan entre sí.

public class Personaje
{
    public void Atacar()
    {
        Console.WriteLine($"{Nombre} ataca con una fuerza de {Fuerza}.");
    }

    public void Defender()
    {
        Console.WriteLine($"{Nombre} se defiende, reduciendo el daño.");
    }
}

Ahora imaginamos que queremos que nuestro personaje Thorin ataque y luego se defienda. Utilizaríamos los métodos de la siguiente manera:

Personaje thorin = new Personaje();
thorin.Nombre = "Thorin";
thorin.Vida = 150;
thorin.Fuerza = 75;

thorin.Atacar(); // Thorin ataca con una fuerza de 75.
thorin.Defender(); // Thorin se defiende, reduciendo el daño.

[Imagen de un personaje en accion]

Constructores

Un constructor es un método especial en una clase que se llama automáticamente cuando se crea un nuevo objeto de esa clase. Su propósito principal es inicializar los atributos del objeto. En C#, un constructor tiene el mismo nombre que la clase y no tiene un tipo de retorno.

En este ejemplo, el constructor Personaje(string nombre) se utiliza para inicializar el nombre del personaje y establecer valores predeterminados para la vida y la fuerza:

public class Personaje
{
    public string Nombre { get; set; }
    public int Vida { get; set; }
    public int Fuerza { get; set; }

    // Constructor
    public Personaje(string nombre)
    {
        Nombre = nombre;
        Vida = 100;
        Fuerza = 50;
    }
}

Cada vez que utilizas "new" haces uso del constructor para crear un objeto.

Sobrecarga

La sobrecarga de métodos, incluido el constructor, permite definir múltiples métodos con el mismo nombre pero con diferentes parámetros. Esto es útil para proporcionar diversas maneras de inicializar un objeto.

Por ejemplo, podríamos tener varios constructores para Personaje que permitan diferentes niveles de detalle en la creación de un personaje:

public class Personaje
{
    public string Nombre { get; set; }
    public int Vida { get; set; }
    public int Fuerza { get; set; }

    // Constructor 1: Sólo nombre
    public Personaje(string nombre)
    {
        Nombre = nombre;
        Vida = 100;
        Fuerza = 50;
    }

    // Constructor 2: Nombre y vida
    public Personaje(string nombre, int vida)
    {
        Nombre = nombre;
        Vida = vida;
        Fuerza = 50;
    }

    // Constructor 3: Nombre, vida y fuerza
    public Personaje(string nombre, int vida, int fuerza)
    {
        Nombre = nombre;
        Vida = vida;
        Fuerza = fuerza;
    }
}

Aquí, hemos definido tres constructores diferentes para Personaje, permitiendo crear objetos con solo el nombre, con nombre y vida, o con nombre, vida y fuerza. Esto da flexibilidad para inicializar objetos según las necesidades del juego.

La sobrecarga también se puede utilizar en los métodos de la clase, no sólo en constructores.

Principios fundamentales de la POO

La Programación Orientada a Objetos se basa en cuatro principios clave que ayudan a construir software más modular, reutilizable y fácil de mantener. Estos principios son Encapsulamiento, Herencia, Polimorfismo, y Abstracción. Vamos a ver de qué se tratan con ejemplos aplicados al desarrollo de un videojuego.

Encapsulamiento

El encapsulamiento consiste en ocultar los detalles internos de un objeto y exponer sólo lo necesario. Esto se logra mediante el uso de propiedades y métodos públicos para interactuar con el objeto, mientras que los detalles internos se mantienen privados.

En el contexto de un videojuego, el encapsulamiento asegura que los atributos de un personaje, como su vida o fuerza, no sean modificados directamente desde fuera de la clase. En cambio, se utilizan métodos para alterar estos atributos, lo que permite agregar lógica adicional, como validaciones.

public class Personaje
{
    private int vida;

    public int Defensa { get; set; }

    public int Vida
    {
        get { return vida; }
        set
        {
            if (value < 0)
                vida = 0;
            else
                vida = value;
        }
    }

    public void RecibirDano(int dano)
    {
        var danoFinal = dano - Defensa;
        Vida = danoFinal <= 0 ? Vida : Vida - danoFinal;
    }
}

En este ejemplo, el atributo vida es privado, y se accede a él mediante la propiedad Vida. El método RecibirDano() controla cómo se reduce la vida del personaje, asegurando que no baje de cero.

El encapsulamiento no sólo protege los datos de cambios no deseados, sino que también facilita el mantenimiento del código al centralizar la lógica relacionada.

Herencia

La herencia permite crear una nueva clase que reutiliza, extiende o modifica el comportamiento de otra clase. Es como crear una plantilla general y luego hacer variantes de ella para casos específicos.

En nuestro videojuego, podemos tener una clase base Personaje y luego derivar clases como Guerrero o Mago que heredan atributos y métodos de Personaje, pero con características adicionales.

public class Personaje
{
    public string Nombre { get; set; }
    public int Vida { get; set; }

    public void Atacar()
    {
        Console.WriteLine($"{Nombre} ataca.");
    }
}

public class Guerrero : Personaje
{
    public int Fuerza { get; set; }

    public void AtacarConEspada()
    {
        Console.WriteLine($"{Nombre} ataca con una espada con fuerza de {Fuerza}.");
    }
}

public class Mago : Personaje
{
    public int Mana { get; set; }

    public void LanzarHechizo()
    {
        Console.WriteLine($"{Nombre} lanza un hechizo utilizando {Mana} de mana.");
    }
}

Aquí, Guerrero y Mago heredan de Personaje, compartiendo propiedades comunes como "Nombre" y "Vida", pero también añadiendo su propia funcionalidad específica.

La herencia debe usarse con cuidado, ya que puede llevar a una estructura de clases compleja y difícil de mantener si se abusa de ella.

Polimorfismo

El polimorfismo permite a los objetos de diferentes clases ser tratados como objetos de una clase base común. En términos simples, permite usar un método de la misma manera para diferentes tipos de objetos.

public void RealizarAccion(Personaje personaje)
{
    personaje.Atacar();
}

Guerrero guerrero = new Guerrero { Nombre = "Thorin", Fuerza = 100 };
Mago mago = new Mago { Nombre = "Gandalf", Mana = 200 };

RealizarAccion(guerrero); // Thorin ataca con una espada con fuerza de 100.
RealizarAccion(mago); // Gandalf lanza un hechizo utilizando 200 de mana.

En este ejemplo, aunque RealizarAccion llama al mismo método "Atacar" en ambos casos, la implementación específica de cada clase derivada es la que se ejecuta.

Abstracción

La abstracción consiste en simplificar la complejidad del sistema al mostrar sólo los detalles esenciales y ocultar los innecesarios. En POO, esto se logra mediante clases abstractas y interfaces, que definen una estructura común sin implementar todos los detalles.

Imaginemos que queremos definir una interfaz IPoder para habilidades especiales que todos los personajes deben tener, pero cada personaje puede implementar estas habilidades de manera diferente.

public interface IPoder
{
    void UsarPoder();
}

public class Guerrero : Personaje, IPoder
{
    public void UsarPoder()
    {
        Console.WriteLine($"{Nombre} usa su poder especial: Golpe Feroz.");
    }
}

public class Mago : Personaje, IPoder
{
    public void UsarPoder()
    {
        Console.WriteLine($"{Nombre} usa su poder especial: Llamas Místicas.");
    }
}

En este ejemplo, Guerrero y Mago implementan la interfaz IPoder, cada uno proporcionando su propia versión del método "UsarPoder".

Podrías realizar el mismo ejemplo utilizando una clase abstracta:

public abstract Poder
{
    void UsarPoder();
}

public class Guerrero : Poder
{
    public void UsarPoder()
    {
        Console.WriteLine($"{Nombre} usa su poder especial: Golpe Feroz.");
    }
}

public class Mago : Poder
{
    public void UsarPoder()
    {
        Console.WriteLine($"{Nombre} usa su poder especial: Llamas Místicas.");
    }
}

El problema es que al ser una clase, no podrás heredera de ninguna otra. Eso a su vez genera un alto acoplamiento. Es por eso que se recomienda utilizar una interface sobre las clases abstractas.

Cohesión y Acoplamiento

En la Programación Orientada a Objetos, dos conceptos clave para escribir código limpio y manejable son la cohesión y el acoplamiento.

Cohesión se refiere a qué tan bien se agrupan las responsabilidades dentro de una clase. Una clase con alta cohesión tiene un propósito claro y realiza un conjunto específico de tareas. Por ejemplo, en un videojuego, una clase Inventario debería manejar todo lo relacionado con los ítems del jugador, y no encargarse de las habilidades o el estado del personaje
Acoplamiento es la medida en que una clase depende de otras. El bajo acoplamiento es deseable porque permite que los cambios en una clase no afecten otras. Imaginemos que tenemos una clase Arma y una clase Personaje. Si Personaje depende demasiado de la estructura interna de Arma, cualquier cambio en Arma podría requerir modificaciones en Personaje. Mantener bajo acoplamiento facilita la reutilización de código y mejora la mantenibilidad.

Al diseñar tus clases, trata de que cada una tenga una única responsabilidad clara (alta cohesión) y minimiza las dependencias entre ellas (bajo acoplamiento). Esto hará que tu código sea más fácil de entender, mantener y expandir.

Una vez que domines estos conceptos podrás mejorar tu código aún más con los principios SOLID y patrones de diseño. 😎

Espero que este post te haya sido de utilidad para entender mejor la POO en C#. Aplica esto en proyectos personales y no compliques el diseño de clases innecesariamente; a veces, la solución más simple es la mejor.

!Happing coding! ☕

Lógica de programación con estructuras de control en C#

Manuel Dávila Alarcón — Tue, 30 Jul 2024 02:57:04 +0000

¿Alguna vez te has preguntado cómo funcionan las aplicaciones que usas todos los días? Desde un simple juego en tu teléfono hasta una aplicación bancaria que gestiona tus finanzas, todos estos programas necesitan tomar decisiones y realizar acciones repetitivas. Y eso es exactamente lo que hacen las estructuras de control en C#.

Imagina que estás desarrollando una aplicación para un servicio de entrega de alimentos. Quieres que la aplicación muestre un mensaje diferente dependiendo de si el pedido está en camino, entregado o cancelado. Aquí es donde entra en juego el condicional "if".

O tal vez estás construyendo una plataforma de streaming que personaliza recomendaciones de series y películas. Necesitas analizar el historial de visualizaciones de cada usuario para sugerir contenido nuevo. Aquí, los bucles "for" y "foreach" son esenciales para recorrer y procesar los datos.

Aquí aprenderemos cómo utilizar las estructuras de control en C# para hacer que nuestros programas tomen el camino que nosotros queremos.

Estructuras condicionales

1. Condicional If

El condicional "if" nos ayuda a decidir si una parte del código se ejecuta o no, dependiendo de si una condición es verdadera. Piénsalo como tomar decisiones en tiempo real en función de lo que está sucediendo.

Imagina que estás desarrollando una aplicación para un servicio de entrega de alimentos. Quieres que los usuarios reciban una notificación cuando su pedido esté listo para ser recogido. Podrías usar un condicional "if" para verificar si el pedido ha cambiado su estado a "listo para recoger". Si es así, envías una notificación al usuario para informarle.

if (pedido.Estado == EstadoPedido.ListoParaRecoger)
{
    EnviarNotificacion("Tu pedido está listo para recoger");
}

En este ejemplo, el condicional "if" verifica si el usuario está inactivo (es decir, "usuarioActivo" es falso). Si lo está, se envía una notificación al usuario.

En este ejemplo, el condicional "if" verifica si el estado del pedido es "ListoParaRecoger". Si la condición es verdadera, se envía una notificación al usuario para informarle que puede ir a recoger su pedido.

2. Condicional If - Else

El condicional "if - else" nos ayuda a manejar situaciones donde hay más de una posible acción a tomar, dependiendo de si una condición es verdadera o falsa. Es como decir "si esto cumple, haz esto; de lo contrario, haz lo otro".

Supongamos que quieres mostrar un mensaje diferente a los usuarios dependiendo de si su pedido ha sido confirmado o no. Aquí es donde el condicional "if - else" resulta útil.

if (pedido.Estado == EstadoPedido.Confirmado)
{
    MostrarMensaje("Tu pedido ha sido confirmado y está siendo preparado.");
}
else
{
    MostrarMensaje("Lo sentimos, tu pedido no ha podido ser confirmado. Por favor, intenta nuevamente.");
}

En este ejemplo, el condicional "if - else" verifica si el estado del pedido es Confirmado. Si el pedido está confirmado, se muestra un mensaje indicando que el pedido está siendo preparado. De lo contrario, se muestra un mensaje informando al usuario que el pedido no ha podido ser confirmado. Esto permite manejar diferentes estados del pedido de manera clara y estructurada.

3. Condicional If - Else If - Else

Las condicionales "if - else if - else" nos permiten evaluar una serie de condiciones en secuencia y ejecutar el bloque de código correspondiente a la primera condición que se cumpla. Es como decir "si esto cumple, haz esto; de lo contrario, si esto otro cumple, haz lo otro; y si ninguna de las anteriores sucede, haz esto otro".

Si estas desarrollando un sistema de cálculo de tarifas de envío para una tienda en línea y dependiendo del peso del paquete y la distancia de envío, el sistema debe calcular diferentes tarifas de envío correspondiente, acá nos ayudaría esta condicional.

Imagina que necesitas calcular el tiempo estimado de entrega en función de la distancia y el tráfico, acá nos ayudaría esta condicional.

if (peso <= 2)
{
    tarifaEnvio = 5.99;
}
else if (peso <= 5)
{
    tarifaEnvio = 9.99;
}
else if (peso <= 10)
{
    tarifaEnvio = 14.99;
}
else
{
    tarifaEnvio = 19.99;
}

MostrarTarifaEnvio(tarifaEnvio);

Es importante ordenar las condiciones de manera lógica y coherente para evitar errores y mejorar la legibilidad del código. El orden de tus condicionales es crucial, ya que una vez que se cumpla una condición, no se evaluarán las siguientes.

Existen los "if anidados", que se utilizan para evaluar múltiples condiciones de manera jerárquica y secuencial. Esto significa que dentro de un "if" se coloca otro bloque de "if", permitiendo tomar decisiones más complejas.

Por ejemplo, si necesitas determinar el tipo de oferta que se le debe mostrar a un cliente basado en su historial de pedidos y la disponibilidad actual de productos, puedes usar if anidados.

if (cliente.HistorialPedidos > 10)
{
    if (producto.Disponibilidad == "Alta")
    {
        MostrarOfertaEspecial("Descuento del 20% en tu próximo pedido");
    }
    else
    {
        MostrarOfertaEspecial("Descuento del 10% en tu próximo pedido");
    }
}
else
{
    MostrarOfertaEspecial("Obtén un 5% de descuento al referir a un amigo");
}

Es una buena práctica refactorizar estos if anidados en un único "if - else if - else" cuando sea posible, para simplificar el código y mejorar su legibilidad.

4. Switch Case

El "switch case" es como una centralita de opciones que elige qué hacer basándose en el valor de una variable. Es especialmente útil cuando tienes varias opciones y cada una requiere una respuesta diferente. Es una alternativa más ordenada al uso de múltiples "if - else if - else".

Si en tu aplicación quieres mostrar mensajes personalizados a los usuarios según el estado de su pedido, utilizar un "switch case" resulta ideal.

switch (pedido.Estado)
{
    case EstadoPedido.Pendiente:
        MostrarMensaje("Tu pedido está pendiente de confirmación.");
        break;
    case EstadoPedido.Confirmado:
        MostrarMensaje("¡Genial! Tu pedido ha sido confirmado y pronto estará en camino.");
        break;
    case EstadoPedido.EnCamino:
        MostrarMensaje("Tu pedido está en camino. ¡Prepárate para disfrutar!");
        break;
    case EstadoPedido.Entregado:
        MostrarMensaje("Tu pedido ha sido entregado. ¡Buen provecho!");
        break;
    case EstadoPedido.Cancelado:
        MostrarMensaje("Lo sentimos, tu pedido ha sido cancelado.");
        break;
    default:
        MostrarMensaje("Estado del pedido desconocido. Por favor, contacta con el soporte.");
        break;
}

Cada "case" corresponde a un estado específico, y el programa ejecuta el bloque de código correspondiente solo si el valor del estado coincide. La instrucción break es importante porque evita que el código continúe ejecutando los siguientes bloques de "case" una vez que se encuentra una coincidencia.

El "switch case" hace que tu código sea más organizado, especialmente cuando hay varias condiciones posibles. Además, mejora la legibilidad y facilita la comprensión de lo que el programa está haciendo en cada situación.

5. Operador ternario

El operador ternario es útil para decisiones rápidas y sencillas, donde solo necesitas asignar diferente valor entre dos opciones. Es como decir "si esto es verdadero, asigna tal valor; si no, asigna esto otro", pero en una sola línea de código.

Imagina que en tu aplicación quieres mostrar un mensaje que indique si el tiempo estimado de llegada es rápido o lento, dependiendo de si es menor o mayor a 30 minutos. El operador ternario es perfecto para este tipo de decisiones rápidas.

string mensajeTiempoEntrega = tiempoEntrega < 30 ? "Entrega rápida, buen provecho!" : "Tu pedido llegará pronto, gracias por tu paciencia.";

MostrarMensaje(mensajeTiempoEntrega);

En este ejemplo, el operador ternario evalúa la condición tiempoEntrega < 30. Si es verdadera, asigna la cadena de texto "Entrega rápida, buen provecho!" a la variable mensajeTiempoEntrega. Si es falsa, asignará "Tu pedido llegará pronto, gracias por tu paciencia.".

Si no tuvieramos el operador ternario, utilizariamos el if-else de la siguiente forma para tener el mismo comportamiento:

string mensajeTiempoEntrega;
if (tiempoEntrega < 30)
{
    mensajeTiempoEntrega = "Entrega rápida, buen provecho!";
}
else
{
    mensajeTiempoEntrega = "Tu pedido llegará pronto, gracias por tu paciencia.";
}
MostrarMensaje(mensajeTiempoEntrega);

Ten en cuenta que este operador sólo se debe usarse para condiciones simples que su acción sea la asignación de algún valor a una variable.

Estructuras repetitivas

6. Bucle While

El bucle While se utiliza para repetir un bloque de código mientras una condición sea verdadera. Es ideal cuando no sabes cuántas veces necesitas repetir el ciclo porque la condición se evalúa antes de cada iteración.

Imagina que en una aplicación de streaming de películas y series, necesitas verificar continuamente si hay una nueva recomendación para el usuario mientras está viendo contenido.

while (!usuario.TerminoDeVerPelicula)
{
    var nuevaRecomendacion = ObtenerSiguienteRecomendacion();
    MostrarRecomendacion(nuevaRecomendacion);
}

En este ejemplo, el bucle while sigue mostrando recomendaciones al usuario hasta que termine de ver la película.

Evita modificar variables externas dentro del bucle que podrían cambiar la lógica de control inesperadamente. A esto se le conoce como "efecto secundario".

7. Bucle Do While

La estructura Do While es similar al While, pero con una diferencia clave: siempre ejecuta el bloque de código al menos una vez antes de verificar la condición. Es útil cuando deseas que el código se ejecute al menos una vez sin importar la condición inicial.

Siguiendo con el ejemplo de la aplicación de streaming, imagina que quieres mostrar un resumen de los episodios de una serie, y si o si necesitas que se muestre el primero.

do
{
    MostrarResumen(episodio);
    episodio = ObtenerSiguienteEpisodio();
} while (episodio != null);

En este caso, el bucle do while muestra un resumen del episodio actual y luego obtiene el siguiente episodio. Esto se repite hasta que no haya más episodios disponibles.

8. Bucle For

El bucle For es ideal para situaciones en las que conoces de antemano cuántas veces quieres repetir un bloque de código. Se usa comúnmente para iterar sobre una secuencia de números o índices.

Por ejemplo, en tu aplicación de streaming, podrías usar un bucle for para mostrar los primeros 5 trailers más populares para el usuario.

for (int i = 0; i < 5; i++)
{
    MostrarTrailer(listaDeTrailers[i]);
}

Aquí, el bucle for se ejecuta cinco veces, mostrando los trailers de la lista en el orden de popularidad.

Siempre debes asegurarte que exista el indice (nuestra variable i) al que accedes. Por ejemplo, si esa lista de trailers solo tuviera 4 elementos, al acceder al 5to obtendríamos un error.

9. Bucle Foreach

Por último el bucle Foreach se utiliza para iterar a través de colecciones como listas o arreglos de manera sencilla. Es ideal cuando quieres recorrer todos los elementos de una colección sin preocuparte por los índices.

Por ejemplo, en el caso anterior sólo queriamos recorrer 5 elementos, pero si quisieramos recorrer todos los trailers, el foreach sería el indicado.

foreach (var trailer in listaDeTrailers)
{
    MostrarTrailer(trailer);
}

Esto es una herramienta poderosa para simplificar el código y evitar errores de índice. Sin embargo, ten en cuenta que no puedes modificar la colección original dentro del bucle, es decir "listaDeTrailers". Para ese tipo de cambios, es mejor usar un bucle for.

Asegurate de que toda estructura repetitiva o bucle cumpla con la condición para finalizar, así no tienes un bucle infinito que genere el famoso StackOverflowException o algún otro.

Así que ahí lo tienes, ¡una inmersión completa al mundo de la lógica de programación utilizando C#!

Puedes poner en práctica tu lógica de programación en plataformas como Codewars o Hackerrank. Te recomiendo empezar con la lógica de resolver el problema antes de pensar en como hacer un código limpio. Una vez que tengas la lógica funcionando, piensa en como puedes optimizarlo.

¿Quién diría que unos simples "if", "while" y "for" podrían ser tan poderosos? Pero recuerda, con gran poder viene gran responsabilidad... ¡y también muchos errores de compilación! 😅

¡Happing coding! 🚀

La Importancia del Unit Testing en el Desarrollo de Software

Manuel Dávila Alarcón — Sat, 22 Jul 2023 23:08:18 +0000

Cuando se trata de desarrollar software de calidad, una de las herramientas más poderosas que tenemos a nuestro alcance es el Unit Testing.

En este artículo, exploraremos de forma sencilla y accesible todos los aspectos clave sobre los unit tests. Descubrirás sus beneficios, cómo se estructuran, técnicas para nombrarlos adecuadamente, qué son los mocks y el Code Coverage, además de las mejores prácticas para escribir unit tests efectivos.

Antes de iniciar quiero que darte un ejemplo de que ocurriría en un proyecto sin pruebas unitarias.

Imagina que estás desarrollando una nueva aplicación web y has llegado a la fase de pruebas en donde esperas cruzar los dedos para no encontrar errores. Pero, sorpresa ⚠️ siempre aparecen problemas de último minuto, como usuarios que pueden registrarse sin proporcionar una dirección de correo electrónico válida.

Aquí es donde entran en juego las pruebas unitarias, un salvavidas para los desarrolladores. En lugar de esperar hasta el final, las pruebas unitarias se hacen a lo largo del proceso de desarrollo. Básicamente, se prueban pedacitos de código, como funciones o métodos, para asegurarse de que funcionen correctamente.

Volviendo a nuestro ejemplo del registro de usuarios, con pruebas unitarias, podríamos haber detectado el error antes. Hubiéramos creado una prueba que verifica si la dirección de correo electrónico es válida o no. Si la prueba falla, sabemos que hay un problema en esa parte del código y podemos arreglarlo de inmediato.

¡No más sorpresas de último minuto!

Las pruebas unitarias no solo nos ayudan a encontrar errores antes, sino que también facilitan la identificación de la causa raíz. De esta forma, se reducen la cantidad de errores que llegan al producto final, ya que en ocasiones estos errores pueden escaparse incluso en la fase de pruebas.

La Pirámide de Testing

Es importante conocer la pirámide de Testing, ya que en base a esta podemos determinar factores como la rapidez de ejecución, costo, volumen y confiabilidad. Esta pirámide se compone principalmente de las pruebas de interfaz de usuario, pruebas de integración y pruebas unitarias.

Unit Test:
- Prueba la unidad de la aplicación sin dependencias externas.
- Son rápidas pero no dan tanta confiabilidad.
Integration Test:
- Prueba la aplicación con dependencias externas.
- Son lentas pero dan más confiabilidad.
End to end Test:
- Prueba toda la aplicación desde la interfaz de usuario.
- Son muy lentas pero dan muchísima confiabilidad.

Como puedes ver las pruebas unitarias son la base de la pirámide de pruebas y al ser componentes individuales aislados, son ejecutadas rápidamente. En caso de que se encuentren errores en este tipo de pruebas, la corrección del mismo es menos costoso para el proyecto ya que sería detectado en la fase de desarrollo y no en un ambiente productivo o de pruebas.

Con dependencias externas nos referimos a base de datos, web services, APIs, cola de mensajes, entre otros.

¿Qué es un Unit Test?

Un Unit Test, o prueba unitaria, es una técnica de prueba en el desarrollo de software que se enfoca en probar unidades individuales de código, como funciones, métodos o clases, de manera aislada. El objetivo principal es verificar que cada unidad de código funcione correctamente por sí misma, independientemente de su integración con el resto del sistema.

Básicamente es un porción de código para probar de porción de código.

Existen Frameworks o librerías para hacer Unit Testing en diferentes lenguajes de programación:

XUnit y NUnit para .NET

JUnit para Java

Jest y Cypress para Javascript

Unittest para Python

Ten en cuenta que no todo el código debe ser probado. Algunos ejemplos de que debe probarse:

Métodos públicos.
Funciones de tipo query o comandos.
Cada ruta de ejecución que puede tomar la función.

Por otro lado, no debería ser probado:

Métodos privados, ya que estos se prueban implícitamente dentro de los públicos.
Features del lenguaje.
Código de terceros como librerías.

Beneficios del Unit Testing

Garantizar que el código haga lo que se supone que debe hacer.
Generar código robusto.
Mejorar la calidad de código productivo.
Permiten hacer Test Driven Development
Detección temprana de errores
Facilita el mantenimiento de código
Fomenta un diseño desacoplado

Estructura de un Unit Test

Un Unit Test generalmente sigue una estructura sencilla pero poderosa. Tiene tres pasos básicos, el famoso AAA: Arrange (Preparación), Act (Acción) y Assert (Verificación).

Arrange: Inicializamos variables u objetos necesarios para la prueba.
Act: Invocamos o llamamos el método que queremos probar.
Assert: Verificar que el valor obtenido sea o no valor esperado.

Para este ejemplo, usaremos el popular de programación FizzBuzz. De forma resumida, si un número es divisible por 3 imprime Fizz, si es divisible por 5 imprime Buzz y si lo es por 3 y 5 a la vez, imprime FizzBuzz, de lo contrario imprime el número.

En estos ejemplos, trato de usar lo menos posible las herramientas que ofrece xUnit para que se pueda aplicar a cualquier tecnología.

Creemos la prueba unitaria para validar la correcta implementación de nuestro método siguiendo la estrategia AAA.

[TestFixture]
public class Tests
{
    [Test]
    public void FizzBuzzTest()
    {
        // Arrange
        var resultadoEsperado = "FizzBuzz";
        var numeroEntrada = 15;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void FizzTest()
    {
        // Arrange
        var resultadoEsperado = "Fizz";
        var numeroEntrada = 3;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void BuzzTest()
    {
        // Arrange
        var resultadoEsperado = "Buzz";
        var numeroEntrada = 5;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void NumberTest()
    {
        // Arrange
        var resultadoEsperado = "7";
        var numeroEntrada = 7;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(numeroEntrada);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }
}

En ocasiones puede haber más de un paso en una misma línea de código.

Técnicas de Naming

El arte de nombrar nuestras pruebas es como elegir nombres para nuestras mascotas. En el caso de Unit Testing, queremos que los tests sean claros y descriptivos. Sin embargo, esto depende de la convención que elija el equipo de Desarrollo en el proyecto.

Mi favorito cumple con la siguiente nomenclatura:

Para el caso de un proyecto: [Nombre de proyecto].UnitTests. Por ejemplo, si el proyecto se llama ApiFly, el proyecto de Unit Test se llamará ApiFly.UnitTests.
Para el caso de las clases: [Nombre de clase]Tests. Por ejemplo, si la clase se llama ServiceTour, la clase de Unit Testing se llamará ServiceTourTests.
Para el caso de los métodos: [Nombre del método]_[Escenario]_[Valor esperado]. Por ejemplo, si el método se llama ValidateFlightDate, el método de Unit Testing se llamará ValidateFlightDate_DateBeforeToday_ReturnFalse.

[TestFixture]
public class ServiceFizzBuzzTests
{
    [Test]
    public void Calculate_WhenIsMultipleThreeAndFive_ReturnFizzBuzz()
    {
        // Arrange
        var resultadoEsperado = "FizzBuzz";
        var numeroEntrada = 15;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void Calculate_WhenIsMultipleThree_ReturnFizz()
    {
        // Arrange
        var resultadoEsperado = "Fizz";
        var numeroEntrada = 3;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void Calculate_WhenIsMultipleFive_ReturnBuzz()
    {
        // Arrange
        var resultadoEsperado = "Buzz";
        var numeroEntrada = 5;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(number);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }

    [Test]
    public void Calculate_WhenIsMultipleThreeAndFive_ReturnFizzBuzz()
    {
        // Arrange
        var resultadoEsperado = "7";
        var numeroEntrada = 7;
        var serviceFizzBuzz = new ServiceFizzBuzz();

        // Act
        var resultadoObtenido = serviceFizzBuzz.Calculate(numeroEntrada);

        // Assert
        Assert.That(resultadoObtenido, Is.EqualTo(resultadoEsperado));
    }
}

Otros desarrolladores prefieren la siguiente nomenclatura:

Para el caso de un proyecto: Agregar ".Tests". Por ejemplo, si el proyecto se llama ECommerce, el proyecto Unit Testing se llamaría ECommerce.Tests.
Para el caso de las clases: Agregar "Should". Por ejemplo, si la clase se llama CatalogService, la clase de Unit Testing se llamaria CatalogServiceShould.
Para el caso de los métodos: Se nombre con lo que debe retornar bajo determinado escenario. Por ejemplo, si el método nos devuelve true si existe algún producto en Stock, sería llamado Return_True_Exists_Stock().

Existen muchas otras más, aunque estas son las más comunes.

Si estas en un equipo, deberás mantener la convención que elijan o que ya este establecida para mantener un estándar.

¿Qué es un mock?

Un mock es como un actor de cine que interpreta a alguien más en una película. En el Unit Testing, es un objeto que simula ser una dependencia externa de nuestra unidad de código. Por ejemplo, si nuestra función depende de una API, en lugar de llamar a la API real en las pruebas, usamos un mock que actúa como si fuera la API. Los mocks nos permiten remover dependencias externas y hacer nuestras pruebas más controladas y predecibles.

Algunas librerías para hacer mocks en nuestras pruebas unitarias:

Moq y NSubstitute para .NET

Mockito y EasyMock para Java

Jest para Javascript

Unittest.mock para Python

¿Qué es el Code Coverage?

El Code Coverage, o cobertura de código, es como una radiografía de nuestro código. Nos muestra cuántas partes han sido cubiertas por nuestras pruebas unitarias.

Por lo tanto, el Code Coverage nos ayuda a evaluar qué tan bien hemos probado nuestro código, identificando las partes que aún no hemos tocado. Una alta cobertura de código nos da la confianza de que estamos cubriendo la mayoría de los rincones de nuestro software.

Es poco probable que a medida que el software crezca se tenga una cobertura de 100%. Pero siempre hay que tratar de mantener un alto porcentaje.

Existen muchas herramientas para medir el Code Coverage, algunas integradas al IDE y otras aisladas del editor como Sonarqube que aparte de darte otras métricas de calidad, también te indica la cobertura de código.

Recomendaciones para tus pruebas unitarias

Crea pruebas unitarias cortas y legibles.
Mantén la independencia en tus pruebas. Para ello, evita utilizar recursos externos y en su defecto usa mocks.
Si tienes que crear muchos test para un único método, revisa detenidamente el método porque probablemente sea mejor una refactorización.
Utiliza alguna técnica de Naming en tus pruebas y mantén el mismo durante todo el proyecto.
Evita duplicación de código en tus pruebas, revisa si puedes crear métodos privados para la reutilización que no generen efectos secundarios.
Evalúa la cobertura de código en tus proyectos. No es necesario tener un 100% pero de 70% para arriba es aceptable.
Testear sólo las interfaces públicas.
No debes crear pruebas tan específicas ni tan generales.
Crear pruebas basada en el número de caminos que puede tomar tu código. Para esto ten en cuenta las condicionales dentro del método que quieres probar.

Espero que te haya servido esta guía sobre Unit Testing y que empieces aplicarlo en tus proyectos 🚀.

¡Happy coding!💻

Introducción a xUnit: Una poderosa herramienta para Unit Testing en .NET

Manuel Dávila Alarcón — Mon, 12 Jun 2023 02:32:51 +0000

xUnit es una tecnología muy popular para hacer pruebas unitarias (unit test) en aplicaciones .NET y en este artículo daremos los primeros pasos.

Esta herramienta se puede usar con C#, F# o Visual Basic. Además, es Open Source, simple y flexible.

Pasos previos a la configuración de xUnit

Es importante que tengas el SDK .NET 7 instalado y tu editor de código preferido, en mi caso utilizaré Visual Studio Code. Si ya lo tienes instalado, crea un directorio y desde la terminal ubicate en la ruta de dicho directorio. Luego, ejecuta el siguiente comando:

dotnet --version

Para poder hacer testing, es necesario tener funcionalidades a probar, pueden ser clases o métodos. Por lo tanto, primero vamos a crear un proyecto simple de biblioteca de clases con el comando:

dotnet new classlib -n FileModule -o FileModule

Dentro del directorio creado llamado FileModule, creamos una clase llamada FileManager con el siguiente código:

namespace FileModule
{
    public class FileManager
    {
        private readonly string directory;

        public FileManager(string directory)
        {
            this.directory = directory;
        }

        public string ReadFile(string fileName)
        {
            if(string.IsNullOrWhiteSpace(fileName))
                throw new ArgumentNullException();

            string filePath = GetFilePath(fileName);

            if (File.Exists(filePath))
                return File.ReadAllText(filePath);

            return string.Empty;
        }

        public void CreateFile(string fileName)
        {
            string filePath = GetFilePath(fileName);
            File.Create(filePath).Close();
        }

        private string GetFilePath(string fileName)
        {
            return Path.Combine(directory, fileName);
        }
    }
}

Configuración inicial: Integrando xUnit en tu proyecto

Una vez finalizado el paso anterior, es momento de crear el proyecto de xUnit para escribir y ejecutar nuestras pruebas unitarias. Para ello puedes ejecutar el siguiente comando:

dotnet new xunit -n FileModule.UnitTests -o FileModule.UnitTests

Tu solución debería estar de la siguiente forma:

A continuación, vamos agregar la referencia del proyecto FileModule a FileModule.UnitTests para poder crear las pruebas unitarias de los métodos con el comando:

dotnet add FileModule.UnitTests reference FileModule

En la clase UnitTest1 que se crea por defecto, colocar el siguiente código con la finalidad de observar la ejecución de una prueba:

namespace FileModule.UnitTests;

public class UnitTest1
{
    [Fact]
    public void Test1()
    {
        Assert.False(false);
    }
}

Las pruebas unitarias no deben retornar valores, es decir deben ser void.

Para ejecutar las pruebas unitarias del proyecto, debemos colocar el siguiente comando:

dotnet test FileModule.UnitTests

Intenta cambiar el false por el true y ejecuta nuevamente el comando, obtendrás una prueba fallida.

Con esto acabas de realizar tu primera prueba unitaria en xUnit.

Estructura básica de un test en xUnit

Atributos

Como observaste en el ejemplo anterior usamos el atributo Fact, el cual sirve para marcar un método como prueba unitaria. Algunos otros atributos más usados:

Theory: Se utiliza para marcar un método como una teoría, las cuales son pruebas parametrizadas que se ejecutan con diferentes conjuntos de datos que se pasan a través del atributo InlineData.
InlineData: Se utiliza en combinación con Theory y permite proporcionar datos para pruebas parametrizadas. Puedes pasar valores directamente a través del atributo, como [InlineData(1, "Maad")], o usar argumentos de tipo simple, como [InlineData("MaadCode")].
MemberData: Se utiliza para pasar datos a una teoría desde una propiedad estática o un campo en la misma clase de prueba o en una clase externa.

Aserciones

Las aserciones sirven para verificar el comportamiento esperado en las pruebas unitarias. Algunos assert más comunes en xunit:

Assert.Equal(expected, actual): Esta aserción verifica si dos valores son iguales. Es útil para comparar el valor esperado con el valor real obtenido durante la prueba.
Assert.True(condition): Comprueba si una condición es verdadera. Se utiliza para validar expresiones booleanas y asegurarse de que se cumplan ciertas condiciones en una prueba.
Assert.False(condition): Comprueba si una condición es falsa. Al igual que Assert.True(), se utiliza para validar expresiones booleanas y asegurarse de que no se cumplan ciertas condiciones en una prueba.
Assert.Null(object): Verifica si un objeto es nulo. Se utiliza para asegurarse de que un objeto esperado no tenga ningún valor asignado.
Assert.NotNull(object): Comprueba si un objeto no es nulo. Es útil para asegurarse de que un objeto esperado tenga un valor asignado.
Assert.Throws(() => { ... }): Verifica si se lanza una excepción durante la ejecución de una acción determinada. Se utiliza para asegurarse de que un código específico genere una excepción esperada.
Assert.InRange(actual, min, max): Comprueba si un valor se encuentra dentro de un rango determinado. Es útil para validar que un resultado se encuentre en un rango específico.
Assert.Collection(expectedCollection, actualCollection): Verifica si dos colecciones contienen los mismos elementos en el mismo orden. Se utiliza para comparar dos colecciones y asegurarse de que sean idénticas.

Es momento de aplicarlo a nuestra prueba. Para eso debemos renombrar el UnitTest1 por FileModuleTest y Test1 por ReadFile_ExistingFile_ReturnsFileContent con el siguiente código:

using FileModule;

namespace FileModule.UnitTests;

public class FileModuleTest
{
    [Fact]
    public void ReadFile_ExistingFile_ReturnsFileContent()
    {
        // Arrange
        var directory = "TestDirectoryFiles";
        var fileNameOriginal = "prueba.txt";
        var content = "Unit Testing with xUnit!";

        Directory.CreateDirectory(directory);
        string filePath = Path.Combine(directory, fileNameOriginal);
        File.WriteAllText(filePath, content);

        var fileName = "prueba.txt";
        FileManager fileManager = new FileManager(directory);
        // Act
        string result = fileManager.ReadFile(fileName);
        // Assert
        Assert.Equal(content, result);
    }

    [Fact]
    public void ReadFile_FileNameIsNull_throwArgumentException()
    {
        // Arrange
        var directory = "TestDirectoryFiles";
        var fileNameOriginal = "prueba.txt";
        var content = "Unit Testing with xUnit!";

        Directory.CreateDirectory(directory);
        string filePath = Path.Combine(directory, fileNameOriginal);
        File.WriteAllText(filePath, content);

        string? fileName = null;
        FileManager fileManager = new FileManager(directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_FileNameIsEmpty_throwArgumentException()
    {
        // Arrange
        var directory = "TestDirectoryFiles";
        var fileNameOriginal = "prueba.txt";
        var content = "Unit Testing with xUnit!";

        Directory.CreateDirectory(directory);
        string filePath = Path.Combine(directory, fileNameOriginal);
        File.WriteAllText(filePath, content);

        var fileName = "";
        FileManager fileManager = new FileManager(directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_FileNameIsWhiteSpace_throwArgumentException()
    {
        // Arrange
        var directory = "TestDirectoryFiles";
        var content = "Unit Testing with xUnit!";
        var fileNameOriginal = "prueba.txt";
        Directory.CreateDirectory(directory);
        string filePath = Path.Combine(directory, fileNameOriginal);
        File.WriteAllText(filePath, content);

        var fileName = " ";
        FileManager fileManager = new FileManager(directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }
}

Aquí estamos aplicando la estrategia triple A (Arrange, Act, Assert) y la técnica de Naming de MethodName_Scenario_ExpectedBehaviour para el nombrado de nuestras pruebas.

Sin embargo, este código esta realizando la misma configuración previa en cada test, el cual consiste en crear el directorio y el archivo con el texto. Por lo tanto, eso lo podemos realizar en el constructor. En otras bibliotecas como NUNit tendrías que usar el atributo SetUp.

using FileModule;

namespace FileModule.UnitTests;

public class FileModuleTest
{
    private string _directory = "TestDirectoryFiles";
    public FileModuleTest() {
        var fileName = "prueba.txt";
        var content = "Unit Testing with xUnit!";

        Directory.CreateDirectory(_directory);
        string filePath = Path.Combine(_directory, fileName);
        File.WriteAllText(filePath, content);
    }

    [Fact]
    public void ReadFile_ExistingFile_ReturnsFileContent()
    {
        // Arrange
        var contentExpected = "Unit Testing with xUnit!";
        var fileName = "prueba.txt";
        FileManager fileManager = new FileManager(_directory);
        // Act
        string result = fileManager.ReadFile(fileName);
        // Assert
        Assert.Equal(contentExpected, result);
    }

    [Fact]
    public void ReadFile_FileNameIsNull_throwArgumentException()
    {
        // Arrange
        string? fileName = null;
        FileManager fileManager = new FileManager(_directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_FileNameIsEmpty_throwArgumentException()
    {
        // Arrange
        var fileName = "";
        FileManager fileManager = new FileManager(_directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_FileNameIsWhiteSpace_throwArgumentException()
    {
        // Arrange
        var fileName = " ";
        FileManager fileManager = new FileManager(_directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_NonExistentFile_ReturnEmptyString()
    {
        // Arrange
        var fileName = "otherfile.txt";
        FileManager fileManager = new FileManager(_directory);
        // Act
        string result = fileManager.ReadFile(fileName);
        // Assert
        Assert.Equal(string.Empty, result);
    }
}

Ahora ejecuta el comando

dotnet test FileModule.UnitTests

en la consola y comprueba que pasen todos los tests.

Ten en cuenta que no sólo se prueban los métodos que retornan un tipo de dato. Por lo tanto, te reto a crear las pruebas unitarias para el método CreateFile.

xUnit para diferentes casos de prueba

Como pudiste ver, en muchas de nuestras pruebas unitarias se espera que se lance una Excepción. Para ello, podemos usar los atributos Theory e InlineData para agrupar casos de prueba que tienen el mismo comportamiento esperado. El código quedaría de la siguiente forma:

using FileModule;

namespace FileModule.UnitTests;

public class FileModuleTest
{
    private string _directory = "TestDirectoryFiles";
    public FileModuleTest() {
        var fileName = "prueba.txt";
        var content = "Unit Testing with xUnit!";

        Directory.CreateDirectory(_directory);
        string filePath = Path.Combine(_directory, fileName);
        File.WriteAllText(filePath, content);
    }

    [Fact]
    public void ReadFile_ExistingFile_ReturnsFileContent()
    {
        // Arrange
        var contentExpected = "Unit Testing with xUnit!";
        var fileName = "prueba.txt";
        FileManager fileManager = new FileManager(_directory);
        // Act
        string result = fileManager.ReadFile(fileName);
        // Assert
        Assert.Equal(contentExpected, result);
    }

    [Theory]
    [InlineData(null)]
    [InlineData(" ")]
    [InlineData("")]
    public void ReadFile_FileNameIsNullOrWhiteSpace_throwArgumentException(string fileName)
    {
        // Arrange
        FileManager fileManager = new FileManager(_directory);
        // Act y Assert
        Assert.Throws<ArgumentNullException>(() => fileManager.ReadFile(fileName));
    }

    [Fact]
    public void ReadFile_NonExistentFile_ReturnEmptyString()
    {
        // Arrange
        var fileName = "otherfile.txt";
        FileManager fileManager = new FileManager(_directory);
        // Act
        string result = fileManager.ReadFile(fileName);
        // Assert
        Assert.Equal(string.Empty, result);
    }
}

Consideraciones

Utiliza estrategias como triple A (Arrange, Act, Assert) para tus pruebas unitarias.
Debes tener una técnica de Naming para tus clases y métodos de prueba. Algunos prefieren nombrar a sus clases de prueba con la palabra Should al final, en nuestro caso usamos Test. Lo importante es mantener dicha técnica con todo el equipo y en todo el proyecto.
Debes identificar lo que debes probar y lo que no.
Tus pruebas unitarias deben ser cortas y deben probar sólo una pequeña porción de funcionalidad.
Existen herramientas en los IDE como Visual Studio, que facilitan la ejecución, depuración y visualización de pruebas unitarias.

Espero que este post te sea de utilidad y lo hayas disfrutado.
¡Happy coding!

Descubre cómo utilizar variables en C# para optimizar tu código: Guía completa

Manuel Dávila Alarcón — Thu, 27 Apr 2023 22:17:01 +0000

Si estás interesado en el mundo de la programación, seguramente has escuchado hablar de C#. Este lenguaje de programación es muy popular y es utilizado por muchas empresas. En este artículo, te explicaré de manera sencilla qué son las variables en C# y cómo puedes utilizarlas para crear programas geniales. ¡Empecemos!

Introducción a las variables en C#: ¿qué son y para qué sirven?

Cuando se programa en C#, se utilizan variables para almacenar temporalmente datos que serán utilizados en el programa. Estas variables pueden guardar diferentes tipos de datos y su valor puede cambiar a lo largo del programa.

Una variable es una zona de memoria reservada en la computadora que tiene un nombre y un tipo de dato. El nombre de la variable se utiliza para hacer referencia en el programa, y el tipo de dato indica qué tipo de información se almacenará en ella. Al asignar un valor a una variable, se guarda el valor en la memoria reservada para esa variable.

Posiblemente en el colegio hayas llevado ecuaciones donde tenias que encontrar el valor de una variable X. Por ejemplo, en la ecuación y = 3x + 5, la variable X representa un valor desconocido que debe ser determinado a partir de otros datos.

De manera similar, en programación, las variables se utilizan para almacenar valores que pueden ser desconocidos al principio pero que deben ser determinados a lo largo del programa. Por ejemplo, una variable edad podría representar la edad de un usuario de un programa, que es desconocida al principio pero que se determina a partir de los datos que proporciona el usuario.

Tipos de variables en C#: enteros, decimales, booleanos y más.

C# es un lenguaje de programación fuertemente tipado, lo que significa que cada variable debe tener un tipo de dato definido en el momento de su declaración. Los tipos de variables más comunes en C# son los siguientes:

Tipo de dato	Descripción
`bool`	Representa un valor booleano, que puede ser verdadero o falso
`byte`	Representa un número entero sin signo de 8 bits
`sbyte`	Representa un número entero con signo de 8 bits
`char`	Representa un carácter Unicode de 16 bits
`decimal`	Representa un número decimal con una precisión de 28-29 dígitos
`double`	Representa un número decimal de punto flotante de 64 bits
`float`	Representa un número decimal de punto flotante de 32 bits
`int`	Representa un número entero con signo de 32 bits
`uint`	Representa un número entero sin signo de 32 bits
`long`	Representa un número entero con signo de 64 bits
`ulong`	Representa un número entero sin signo de 64 bits
`object`	Representa cualquier tipo de objeto
`short`	Representa un número entero con signo de 16 bits
`ushort`	Representa un número entero sin signo de 16 bits
`string`	Representa una secuencia de caracteres Unicode

Si bien C# es un lenguaje fuertemente tipado, podemos crear variables con un tipo dinámico utilizando la palabra reservada dynamic como tipo de dato. A continuación, un ejemplo de como podemos asignar a una variable diferente tipos de datos con dynamic.

dynamic variableConTipadoDinamico = "Hello";
Console.WriteLine(variableConTipadoDinamico.GetType()); // Aquí es un String
variableConTipadoDinamico = 10;
Console.WriteLine(variableConTipadoDinamico.GetType()); // Aquí es un Int
variableConTipadoDinamico = true;
Console.WriteLine(variableConTipadoDinamico.GetType()); // Aquí es un Boolean

Declaración y asignación de variables en C#: cómo empezar a usarlas.

En C#, declarar y asignar variables es una tarea muy sencilla. Para declarar una variable, se utiliza la sintaxis tipoDeDato nombreDeVariable;. Mientras que para asignar se utiliza nombreDeVariable = valor;.

byte edad; // Esto es una declaración
edad = 20; // Esto es una asignación

¿Y si queremos declara y asignar al mismo tiempo? Podemos hacerlo en la misma línea de la siguiente forma :

byte edad = 20; // Declaración y asignación en la misma línea

Sin embargo, existe otra forma para crear variables cuando declaramos y asignamos su valor en la misma línea, utilizando la palabra reservada var. Esto nos ayuda a declarar variables con el tipo de dato implícito, es decir sin especificar el tipo de dato a la variable, ya que tomará el tipo de dato que se le asigne.

// Declaración explícita
string name = "Maad";
Console.WriteLine(name.GetType()); // String

// Declaración implícita
var fullname = "Maadcode";
Console.WriteLine(fullname.GetType()); // String
var edad = 21;
Console.WriteLine(edad.GetType()); // Int

Tener en cuenta que esta forma sólo funciona cuando declaras y asignas en la misma línea, si sólo declaras una variable usando var sin asignarle un valor tendrás un error, ya que el compilador no podrá identificar el tipo de dato.

Operaciones con variables en C#: aritméticos, lógicos y de comparación.

En programación, las operaciones con variables son fundamentales. Aquí te mostramos cómo realizar operaciones básicas en C#.

Operadores Aritméticos :

Operación	Descripción	Ejemplo
`+`	Suma dos valores.	`int resultado = 5 + 3; // resultado = 8`
`-`	Resta dos valores.	`int resultado = 7 - 2; // resultado = 5`
`*`	Multiplica dos valores.	`int resultado = 4 * 6; // resultado = 24`
`/`	Divide dos valores.	`int resultado = 15 / 3; // resultado = 5`
`%`	Obtiene el resto de una división.	`int resultado = 10 % 3; // resultado = 1`
`++`	Aumenta en 1.	`int resultado = 1; resultado++; // resultado = 2`
`--`	Reduce en 1.	`int resultado = 1; resultado--; // resultado = 0`

Operadores Lógicos :

Operación	Descripción	Ejemplo
`&&`	AND lógico. Devuelve `true` si ambas expresiones son verdaderas.	`bool resultado = (true && true); // resultado = true`
`\|\|`	OR lógico. Devuelve `true` si al menos una de las expresiones es verdadera.	`bool resultado = (true \|\| false); // resultado = true`
`!`	NOT lógico. Niega la expresión dada.	`bool resultado = !(true); // resultado = false`

Operadores de comparación :

Operación	Descripción	Ejemplo
`==`	Igualdad. Devuelve `true` si ambas expresiones son iguales.	`bool resultado = (10 == 10); // resultado = true`
`!=`	Desigualdad. Devuelve `true` si ambas expresiones son diferentes.	`bool resultado = (10 != 15); // resultado = true`
`<`	Menor que. Devuelve `true` si el valor de la izquierda es menor al de la derecha.	`bool resultado = (10 < 15); // resultado = true`
`>`	Mayor que. Devuelve `true` si el valor de la izquierda es mayor al de la derecha.	`bool resultado = (15 > 10); // resultado = true`
`<=`	Menor o igual que. Devuelve `true` si el valor de la izquierda es menor o igual al de la derecha.	`bool resultado = (15 <= 15); // resultado = true`
`>=`	Mayor o igual que. Devuelve `true` si el valor de la izquierda es mayor o igual al de la derecha.	`bool resultado = (10 >= 10); // resultado = true`

Reglas y convenciones para nombrar variables en C#: buenas prácticas a tener en cuenta.

Cuando estás programando en C#, es muy importante nombrar tus variables de forma clara y concisa para que otros desarrolladores puedan entender fácilmente el código. Para hacerlo bien, hay algunas reglas y convenciones que debes seguir.

1. Utilizar nombres descriptivos

Es recomendable utilizar nombres de variables que sean descriptivos y que den una idea clara del propósito de la variable. Esto ayudará a otros desarrolladores a entender rápidamente lo que la variable representa, lo que puede mejorar la legibilidad del código.

// Supongamos que queremos aplicar un descuento de 5% a un producto cuando su precio es mayor a 1200
var dscto = 0.05;
var prod = 1500d; // Usamos la letra d al final del número para indicar que es un double, sino lo agregas creara la variable tipo int, la otra opción es que indiques explicitamente que es un double
var total = 0d;
if(prod >= 1200)
    total = prod - (prod * dscto);
else
    total = prod;
Console.WriteLine(total);

Con el código anterior no es claro a que se refiere cada variable, tendríamos que leer todo el código y debuggear para entender, lo cual tomaría tiempo innecesario. Entonces, ¿cómo podemos hacer este código más legible? Veamos.

var porcentajeDescuento = 0.05;
var precioDeProducto = 1500d;
var totalAPagar = precioDeProducto;
if(precioDeProducto >= 1200)
    totalAPagar -=  (precioDeProducto * porcentajeDescuento);
Console.WriteLine(totalAPagar);

Ya quedo mucho mejor. Sin embargo, ese número 1200 que se encuentra en la condicional, es número mágico y debemos evitarlo. Un número mágico es un valor que representa algún dato significativo para el negocio pero es posible que otro desarrollador nuevo no comprenda dicho valor si no tiene contexto.

Modifiquemos el código para evitar ese número mágico.

const double PRECIO_APLICABLE_DESCUENTO = 1200;
var porcentajeDescuento = 0.05;
var precioDeProducto = 1500d;
var totalAPagar = precioDeProducto;
if(precioDeProducto >= PRECIO_APLICABLE_DESCUENTO)
    totalAPagar -=  (precioDeProducto * porcentajeDescuento);
Console.WriteLine(totalAPagar);

Posiblemente vas a tener que crear variables de tipo boolean, es decir que sólo puede ser true o false. En ese caso, puedes usar un truco para verificar si es legible, para ello debes crear una pregunta de la siguiente forma : ¿[nombre de variable]? y la respuesta sólo puede ser Sí/No.

¿No quedó claro? Siguiendo el código de ejemplo anterior, supongamos que creaste una variable boolean llamada aDescontar entonces la pregunta que formularias sería ¿A descontar? Sí/No. Como puedes ver no es muy claro, por lo tanto hay que buscar otro nombre que sea más entendible, por ejemplo, si lo llamamos aplicaDescuento, tendríamos la siguiente pregunta ¿Aplica descuento? Sí/No. Este último es mucho más entendible, por lo tanto ya encontraste el nombre ideal para tu variable.

const double PRECIO_APLICABLE_DESCUENTO = 1200;
var descuento = 0.05;
var precioDeProducto = 1500d;
var totalAPagar = precioDeProducto;
var aplicaDescuento = precioDeProducto >= PRECIO_APLICABLE_DESCUENTO; // Nuestra variable legible
if(aplicaDescuento)
    totalAPagar -=  (precioDeProducto * descuento);
Console.WriteLine(totalAPagar);

2. Utilizar nombres en inglés

Aunque no es obligatorio, es recomendable utilizar nombres de variables en inglés, ya que es el idioma que se utiliza comúnmente en la documentación y en la comunidad de desarrollo de software.

Sin embargo, otro motivo por el que recomiendo usar variables en inglés (si es que el proyecto en el que estas te lo permite), es porque crear nombres de variables es mucho más sencillo en este idioma, ya que el español tiene muchas reglas gramaticales que eventualmente tendrás problema con alguna palabra o letras como la ñ.

Por otro lado, los nombres de las clases o métodos que usarás de librerías nativas de la tecnología que estés usando, están en inglés, por lo que terminarás con un proyecto en spanglish.

3. Técnicas de Naming para mejorar la legibilidad

Es posible que te encuentres con que una palabra no es suficientemente descriptivo para tu variable, para ello existen las técnicas de Naming, las más populares son: Camel Case, Pascal Case, Snake Case, Kebab Case. En los ejemplos anteriores hemos hecho uso de estas.

Técnica de Naming	Descripción	Ejemplo
Camel Case	Escribir palabras juntas sin espacios, cada palabra adicional comienza con mayúscula.	ejemploDeCamelCase
Pascal Case	Escribir palabras juntas sin espacios, cada palabra comienza con mayúscula.	EjemploDePascalCase
Snake Case	Escribir palabras separadas por guiones bajos.	ejemplo_de_snake_case

// Ejemplo de variables escritas en Camel Case
int contadorDeVotos = 0;
string textoDeError = "No se pudo cargar el archivo.";

// Ejemplo de variables escritas en Pascal Case
int Edad = 27;
string NombreCompleto = "Ana Garcia";

// Ejemplo de variables escritas en Snake Case, usando principalmente en Constantes
const double PRECIO_APLICABLE_DESCUENTO = 1200;
const int CODIGO_POR_DEFECTO = 999;

Consejos para trabajar con variables en C

Si vas a realizar la misma operación en diferentes partes del mismo método, es mejor crear una variable local que guarde el resultado de esa operación. De esta manera, se evita realizar la operación varias veces y se mejora el rendimiento del código. Además, el uso de una variable local puede hacer que el código sea más legible y fácil de entender para otros desarrolladores que puedan trabajar en el mismo proyecto.

Utiliza tipos de datos adecuados para los valores que vas a almacenar. Por ejemplo, si necesitas almacenar números enteros pequeños como la edad de un usuario, utiliza tipos byte en lugar de int. Esto puede ahorrar espacio en memoria y mejorar el rendimiento.

Usa el modificador const para crear constantes, es decir valores que no cambian en tiempo de ejecución. Esto permite al compilador optimizar el código eliminando la necesidad de asignar memoria dinámica para estas variables.

Utiliza nombres descriptivos y en inglés para tus variables que sean fáciles de leer para otros desarrolladores.

Crea estándares en tus proyectos usando las técnicas de Naming para una mejor legibilidad y homogeneidad. De esta forma se mantiene el mismo formato en los nombres de variables en todo el proyecto.