La tarea de prueba

Piensa en ellos como un mal necesario o un gimnasio para perfeccionar tus habilidades de codificación. Ámalos o acepta de mala gana su existencia, si aspiras a ser programador, las tareas de prueba suelen ser ineludibles. Sí, aquí estamos hablando de tareas de prueba.

En esta conferencia, exploraremos los diferentes tipos de tareas de prueba y la mejor manera de abordarlas, incluidos los aspectos que a menudo se pasan por alto.

Tipos de tareas de prueba

• Tareas de larga duración (desde 3 días hasta una semana o incluso dos): Son desafíos tipo maratón.
• Tareas cortas (2-3 horas): normalmente, recibes una llamada, recibes la tarea y, unas horas más tarde, llega el momento de enviar todo lo que hayas logrado.< /li>

Etapas para completar una tarea de prueba

Para evitar perderse, recomendamos dividir la solución en varias etapas. Echemos un vistazo.

Etapa de preparación (¡antes de que comience la codificación!)

Comprender la tarea: Esto es crucial. También en la programación del mundo real, es muy importante asegurarse de conocer los requisitos del cliente.

Haga preguntas si algo no está claro: a veces, las tareas son deliberadamente vagas para generar preguntas. Preguntar a menudo puede revelar el nivel de un desarrollador. Por lo general, obtendrás respuestas, pero a veces es posible que te pidan que procedas como mejor te parezca, poniendo a prueba tu responsabilidad y creatividad.

Considere los casos límite: en términos más simples, piense en las entradas de datos más grandes y más pequeñas posibles. Por ejemplo, si tienes la tarea de crear un acortador de URL, considera una cadena vacía o una excepcionalmente larga.

Piense en todas las comprobaciones, los resultados y lo que está dentro o fuera del escenario empresarial de la tarea: comprenda lo que se espera como entrada y salida. Para el ejemplo del acortador de URL, un escenario empresarial recibe un enlace, mientras que un escenario no empresarial recibe un enlace sin enlace. Dado que las comprobaciones adicionales requieren más tiempo, hable con el emisor de la tarea si deben considerarse. Esto demuestra que comprende la necesidad de realizar dichos controles.

Solo después de una planificación y aclaración minuciosas, pase a la codificación.

Etapa de codificación

Empiece con un borrador: No busque un código perfecto y estructurado de inmediato, ya que lleva mucho tiempo. El objetivo principal es la funcionalidad. Implemente lo mínimo indispensable para resolver la tarea, verifique la corrección de su solución, aborde todas las comprobaciones y casos extremos. Inicialmente, una única clase principal grande podría ser suficiente. A veces, es posible que descubras que tu solución no encaja y, si ya planificaste todas las clases y patrones para la solución incorrecta, es simplemente una pérdida de tiempo.

Una vez que el código funcione correctamente y se confirme tu hipótesis, procede con la refactorización iterativa: mejora gradualmente el código sin romper nada. Si el tiempo lo permite, cree clases más pequeñas, aplique los patrones necesarios, etc., hasta lograr un código limpio y cumplir con los principios SOLID.

Cubra su código con pruebas: Si no hay tiempo suficiente para refinar el código por completo, al menos divídalo en clases y cúbralo con pruebas. Las pruebas son cruciales ya que a menudo revelan problemas de manera efectiva.

Etapa de presentación

Si su tarea es crear una aplicación web, puede implementarla. Sin embargo, es mejor discutir este momento con antelación y revisar cuidadosamente las condiciones. A veces, se desaconseja la implementación y el uso de GitHub, y otras veces se recomienda.

Después de resolver la tarea, refactorizar el código y cubrir todo con pruebas, es hora de comenzar a formatear la tarea de prueba: Escribe un archivo Léame explicando tu solución y describiendo las clases principales. A veces, es posible que no tenga contacto directo con la persona que revisa su tarea de prueba, e incluso es posible que no se produzca una conversación. Si su archivo Léame tiene un formato que facilite al revisor verificar su trabajo, aumentan las posibilidades de obtener un resultado positivo.

¿Qué se debe incluir en una tarea de prueba (especialmente una larga)?

Imprescindibles:

• README (hace que todo sea fácil de verificar),
• Uso de Maven/Gradle (demuestre que puede manejar estas tecnologías),
• Principios SOLID,
• Integración y pruebas unitarias,
• Código limpio.

Es bueno tenerlo:

• Registro,
• Sube el proyecto a GitHub (a menos que se indique lo contrario),
• Aplicar CI/CD,
• Docker/Docker-compose,
• Migración de base de datos,
• Arrogancia,
• Implementación.

¡Importante! Después de enviar la tarea, solicite siempre comentarios. Incluso si lo rechazan, pregunte qué había de malo en su código. Esto le ayudará a comprender si la decisión de la empresa fue objetiva o no.