JS, Node.js, Frontend, Backend, Firebase, Express, Patrones, HTML5_APIs, Asincronía, Websockets, Testing
Revisión de código es la examinación sistemática (como en la revisión por pares) del código fuente de un programa informático. Se practica con el objetivo de mejorar la calidad del código que se genera en el proceso de desarrollo del software, mediante la detección temprana de errores en el código de los programas o alternativas más eficientes a la implementación inicial. También se utiliza como técnica para mejorar las cualidades de los desarrolladores involucrados en la práctica, mediante la discusión abierta de posibles mejoras en el programa.
Se realizan principalmente revisiones de código por parte de las metodologías ágiles que practican programación en pareja como parte del proceso, o en otras que pueden implementar revisiones periódicas de código, tanto informales como formales. Wikipedia
Las claves
- Forma parte de algunas metodologías ágiles
- Mejora la comunicación y la calidad del grupo
- No culpar a nadie, ni tomarselo personal
- La culpa de un bug es ahora compartida
- Se sugieren los cambios y se discuten
¿Que revisar?
- Arquitectura/Diseño (patrones, errores potenciales, manejo de errores, eficiencia...)
- Estilo (Longitudes, legibilidad, nombres...)
- Testing (Cobertura, mocks, etc...)
Herramientas
La Programación en Pareja (o Pair Programming en inglés) requiere que dos programadores participen en un esfuerzo combinado de desarrollo en un sitio de trabajo. Cada miembro realiza una acción que el otro no está haciendo actualmente: Mientras que uno codifica las pruebas de unidades el otro piensa en la clase que satisfará la prueba, por ejemplo.
La persona que está haciendo la codificación se le da el nombre de controlador mientras que a la persona que está dirigiendo se le llama el navegador. Se sugiere a menudo para que a los dos socios cambien de papeles por lo menos cada media hora o después de que se haga una prueba de unidad. Wikipedia
Lo bueno
- Mejor código
- Equipo más fuerte y cohesionado
- Se aprende mucho más
- Mejora la propiedad colectiva del código
- Mejora las habilidades sociales
- Reduce el número de bugs
Lo malo
- No todo el mundo se siente cómodo
- No es facil juntar niveles distintos
- Es dificil combinar tiempos (balance, vida personal, etc....)
- Es más dificil en remoto
- Los tiempos de desarrollo son distintos
Las claves
- Persona especializada en asegurar la calidad del proyecto
- Se encarga del diseño y ejecucción de pruebas
- Se encarga de validar la caldiad técnica (rendimeinto, optimización, etc...)
- Define standares, medidas y metricas que debemos cumplir
- Revisa y mantiene seguimiento de la calidad
- Coordina el testeo
- Las funciones pueden cambiar entre proyectos y empresas
Recursos
- ¿Qué es QA y por qué no debe faltar en tu proyecto?
- ¿Que es un QA Tester?
- Tester vs Quality Assurance
- Wikipedia | Aseguramiento de la calidad
- Qué es QA
- Quality Assurance no es sólo Testing
- La misión del QA Manager dentro de la Organización
- QA (Quality Assurance) y su mundo
Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad. Wikipedia
Tipos de pruebas
- Estáticas, No necesitan ejecutar código alguno
- Dinámicas, que requieren ejecucción de código
Según su ejecucción
- Manuales, requieren de nuestra interacción para funcionar
- Automáticas, la propia máquina es capaz de relaizar las pruebas sin sufrir alteraciones
Según el enfoque
- Caja Blanca, nos centramos en el funcionamiento interno de las cosas
- Caja Negra, nos centramos en las entradas (input) y salidas (output) de las clsas y no en su funcionamiento
- Pruebas aleatorias, variante de la caja negra donde el input es aletorio
- Pruebas unitarias (Unit Testing)
- Pruebas de integración (Integration testing)
- Pruebas de sistema (System testing)
- Pruebas de sanidad (Sanity check)
- Pruebas de humo (Smoke testing)
- Pruebas alpha (Alpha Testing)
- Pruebas beta (Beta Testing)
- Pruebas de aceptación (Acceptance Testing)
- Pruebas de regresión (Regression testing)
- Pruebas de compatibilidad
- Pruebas de Accesibilidad (Accessibility testing)
- Pruebas de seguridad (Security Testing)
- Pruebas de destrucción (Destructive testing)
- Pruebas de Stress (Stress Testing)
- Pruebas de Carga (Load Testing)
- Pruebas de usabilidad (Usability testing)
- Pruebas de rendimiento (Performance Testing)
- Pruebas de internacionalización y localización
- Pruebas de escalabilidad
- A/B testing
- Pruebas de concurrencia (Concurrent testing)
- Prueba de conformidad (Conformance testing)
- Unit Testing
- Integration testing
- End-To-End Testing (e2e)
- Alpha & Beta Testing
- Accessibility testing
- Security Testing
- Stress Testing & Load Testing
- A/B testing
Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica de ingeniería de software que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido. Wikipedia
Las claves
- Implementar solo lo necesario
- Evitar bugs a toda costa
- Creamos software modular y reutilizable
- No tener miedo de tocar "legacy"
El Ciclo de desarrollo
- Elegir un requisito
- Escribir las pruebas
- Verificar que fallan las pruebas
- Escribir suficiente código para pasar las preubas
- Pasar las pruebas
- Refactorizar y pasar las pruebas (hasta estar listo)
- El requisito ha sido implementado
Filosofías derivadas
Recursos
- ¿Cuál es la diferencia entre Unit Testing, TDD y BDD?
- BDD + TDD para descubrir el diseño de tu código
- TDD, BDD & Test de Aceptación
- TDD vs BDD vs ATDD
- BDD y TDD en el mundo real (I) – Metodologías y herramientas
- BDD y TDD en el mundo real (II) – Ciclo desde la fuente
- The Difference Between TDD and BDD
- Orígenes de TDD, BDD, ATDD y sus diferencias
- Wikipedia | Desarrollo guiado por comportamiento
- ¿ATDD? ¿BDD?… ¿Cómo? Aclarando el lío de siglas en Testing
- Youtube | BDD vs TDD (explained)
- De testers y code reviews
