Programación Web 3
Frameworks
• Un framework es una estructura de
trabajo que proporciona una base sobre
la cual los desarrolladores pueden
construir aplicaciones. Los frameworks
para el desarrollo web back-end, como
Django, Ruby on Rails o Laravel, ofrecen
herramientas y bibliotecas que facilitan
la creación de aplicaciones robustas y
escalables. Estos frameworks permiten
seguir prácticas de desarrollo
estandarizadas, lo que mejora la
eficiencia y reduce errores.
• Configurar un proyecto con un framework implica
varios pasos esenciales que preparan el entorno de
desarrollo. Primero, se instala el framework en el
sistema utilizando herramientas de gestión de
paquetes como pip para Python, gem para Ruby o
Configuración composer para PHP. Una vez instalado, se crea una
nueva aplicación utilizando comandos específicos
de un del framework, lo que genera una estructura de
Proyecto con directorios organizada. Luego, se configuran los
archivos de configuración para conectar la aplicación
un Framework con bases de datos y otros servicios necesarios. Este
proceso también incluye la instalación de
dependencias adicionales que el proyecto pueda
necesitar y la configuración de variables de entorno
para manejar diferentes configuraciones según el
entorno de despliegue.
• React: Una biblioteca para construir interfaces de usuario, desarrollada
por Facebook.
Frameworks • Angular: Un framework desarrollado por Google para construir
aplicaciones web de una sola página.
Front-End - • [Link]: Un framework progresivo para construir interfaces de usuario,
JavaScript conocido por su simplicidad y flexibilidad.
• Svelte: Un framework que convierte los componentes en JavaScript
eficiente en tiempo de compilación
Frameworks Front-End -
TypeScript
• Angular: Aunque también puede usarse
con JavaScript, Angular está diseñado
para ser utilizado con TypeScript.
• [Link]: Un framework de React que
ofrece capacidades de renderizado del
lado del servidor y generación de sitios
estáticos.
• [Link]: Un framework basado en [Link]
que permite la creación de aplicaciones
universales o SPA.
Frameworks Back-
End - Python
• Python:
• Django: Un framework de alto nivel que permite
el desarrollo rápido y el diseño limpio y
pragmático.
• Flask: Un microframework ligero que
proporciona la flexibilidad de construir
aplicaciones web con pocas dependencias
externas.
• FastAPI: Un framework moderno y rápido para
construir APIs con Python 3.6+ basado en
estándares como OpenAPI y JSON Schema.
Frameworks
Back-End - Ruby
• Ruby on Rails: Un framework de
desarrollo web de código abierto que
sigue el principio de "convención
sobre configuración".
Frameworks
Back-End - JAVA
• Spring: Un framework
extensivo y flexible para la
creación de aplicaciones
empresariales en Java.
• Struts: Un framework
para el desarrollo de
aplicaciones web basadas
en Java EE.
Frameworks Back-End
JavaScript/TypeScript
([Link])
• Express: Un framework
minimalista y flexible para
aplicaciones web en [Link].
• NestJS: Un framework para
construir aplicaciones del lado
del servidor con [Link],
utilizando TypeScript.
Frameworks Back-
End - PHP
• Laravel: Un framework PHP con una
sintaxis elegante y expresiva.
• Symfony: Un framework PHP para
aplicaciones web y una colección de
componentes PHP reutilizables.
• CodeIgniter: Un framework PHP con
una huella pequeña, diseñado para
desarrolladores que necesitan un
toolkit simple y elegante.
Frameworks Back-
End Go
• Gin: Un framework web de
bajo costo con una
excelente capacidad de
rendimiento.
• Beego: Un framework
completo para
aplicaciones web en Go.
Frameworks Back-
End - Rust
• Rocket: Un framework web
para Rust que enfatiza la
seguridad, velocidad y
facilidad de uso.
• Actix: Un framework web
altamente concurrido para
Rust basado en el actor
model.
El desarrollo guiado por pruebas (TDD) es una
metodología de desarrollo de software que enfatiza
la creación de pruebas antes de escribir el código
funcional. Este enfoque comienza con la redacción
de una prueba para una pequeña unidad de
Desarrollo funcionalidad que aún no existe. La prueba
inicialmente fallará, lo que indica que se debe
Guiado por escribir el código necesario para pasar la prueba.
Una vez que el código pasa la prueba, se puede
Pruebas refactorizar para mejorar su calidad sin cambiar su
comportamiento. TDD ayuda a garantizar que el
código sea confiable y que cualquier cambio futuro
no rompa las funcionalidades existentes. Esta
práctica promueve un ciclo de desarrollo más
seguro y sostenible.
Las pruebas y funcionalidad existente
• Uno de los principios del desarrollo ágil de software señalaba que el cambio de los
requerimientos es algo esperado; por lo tanto, el diseño de software debe facilitar la
implementación de los cambios requeridos. Las pruebas automáticas de software
ayudan a verificar que los cambios en el diseño no hayan afectado la funcionalidad del
sistema; en este sentido, las pruebas de software promueven un escenario favorable a
la mejora continua del diseño reduciendo el miedo a romper la funcionalidad del
sistema como consecuencia de un rediseño. Entonces, mientras más exhaustiva la
batería de pruebas, mayor cobertura para detectar posibles errores introducidos al
reorganizar el código. En definitiva, una batería de pruebas automáticas incrementa la
productividad (es posible verificar inmediatamente el efecto de un cambio sin recurrir a
“tiempo de depuración”) y la calidad del software.
• En líneas generales consiste en plantear una hipótesis sobre un
comportamiento del sistema que queremos desarrollar y luego
corroborar esa hipótesis o comportamiento con el código que se
Las pruebas y está escribiendo. Siempre tratando que el código que valida la
hipótesis sea el mínimo posible para validarla y así evitar caer en
nueva sobre ingeniería.
funcionalidad • El proceso de Desarrollo Guiado por Pruebas (TDD) consiste en
iteraciones sobre un ciclo de tres etapas: Red-Green-Refactor. En
cada iteración se aborda una nueva hipótesis sobre el
comportamiento que deseamos en el sistema.
TDD
Red (Rojo): Se escribe un test automatizado para una nueva funcionalidad que falla inicialmente, ya que la
funcionalidad aún no se ha implementado. Este paso garantiza que el test es válido, es decir que falla
porque el comportamiento deseado no está implementado, y necesita la nueva funcionalidad para pasar.
Green (Verde): Se escribe el código mínimo necesario para que el test pase. Este paso se centra en hacer
que el test pase lo más rápido posible, sin detenerse en la perfección del código.
Refactor (Refactorización): Una vez superado el test, el código se ajusta para mejorar su estructura y
calidad, mientras los tests siguen funcionando. Esto incluye eliminar redundancias y mejorar la legibilidad.
Repetir el ciclo
anterior para ir
desarrollando
gradualmente
la
funcionalidad
requerida
Las 3 leyes del TDD
No puedes escribir más
No puedes escribir Solo puedes escribir
de un único test unitario,
código de producción sin código de producción
con el suficiente código
antes hacer un test para hacer pasar el único
para hacerlo fallar (error
fallido. test fallido.
de compilación es fallo).
Beneficios del TDD
• Algunos de los efectos positivos resultantes de la
aplicación de estas reglas son:
• La especificación existe como código antes que la
funcionalidad
• La creación de las pruebas y la funcionalidad avanzan
de manera casi paralela y sincronizada; no existe una
fase de desarrollo y una de prueba.
• En una sesión de desarrollo se intercalan periodos de
diseño (creación de la especificación como una prueba)
e implementación (el código necesario para pasar la
prueba)
• Crear las pruebas antes que la funcionalidad promueve
el desarrollo de un diseño con una funcionalidad fácil
de verificar
Beneficios del TDD a nivel técnico
Mejora la calidad del software: El Desarrollo Guiado por Pruebas (TDD) aumenta la fiabilidad del código, permitiendo realizar
cambios en el sistema con mayor facilidad y confianza.
Fomenta un desarrollo ágil: Aunque inicialmente el TDD puede parecer que ralentiza el proceso de desarrollo, a largo plazo lo
hace más eficiente al reducir el tiempo dedicado a depurar y corregir errores.
Diseño de software mantenible: TDD contribuye a un mejor diseño del software, haciéndolo más completo y mantenible,
especialmente cuando se aplican principios de diseño adecuados.
Cobertura contra regresiones: Genera una red de seguridad contra regresiones al garantizar que el código funciona según lo
previsto.
Cultura de QA: Se alinea con una cultura de aseguramiento de calidad (QA) al escribir código que está pensado para ser
testeado.
Estructura en el desarrollo: Aporta una estructura clara al proceso de desarrollo.
Reducción de feedback loops: Reduce los ciclos de retroalimentación, permitiendo despliegues más rápidos y seguros.
Beneficios del TDD para el negocio
Reducción de costes a largo
Mantenimiento y escalabilidad:
plazo: El Desarrollo Guiado por
TDD reduce los riesgos asociados Mayor satisfacción del cliente:
Pruebas (TDD) favorece la
al mantenimiento y la Aumenta la satisfacción y fidelidad
disminución de costes a largo
escalabilidad del software, ya que de los clientes gracias a la mejora
plazo al reducir el tiempo y los
un código bien diseñado y probado en la calidad del producto.
recursos necesarios para depurar
es más fácil de mantener y escalar.
errores.
Facilita la incorporación de
Aceleración del Time to Market:
Elevación técnica del equipo: nuevos desarrolladores: Los
Facilita la integración y entrega
Mejora el nivel técnico del equipo y tests actúan como documentación
continua (CI/CD), acelerando el
contribuye a la retención del viva, reduciendo la barrera de
lanzamiento de nuevos productos
talento. entrada para nuevos
y funciones.
desarrolladores/ras.
Desafíos al adoptar TDD
Curva de aprendizaje inicial: Tiempo y costos iniciales: Cambio cultural: TDD no es Mantenimiento de tests: A Integración con sistemas
Para equipos no Escribir tests antes del solo una técnica de medida que el proyecto existentes: Aplicar TDD en
familiarizados con TDD, código funcional puede desarrollo; es una filosofía crece, también lo hace el sistemas legados o en
aprender a escribir tests parecer que ralentiza el que requiere un cambio conjunto de tests. Mantener proyectos en marcha puede
efectivos antes del código de progreso al principio, cultural dentro del equipo de los tests actualizados con ser un reto ya que no han sido
producción requiere un especialmente en las etapas desarrollo. Adoptar TDD cambios en el código y diseñados con la mentalidad
cambio de mentalidad y la tempranas de un proyecto significa cambiar la nuevos requisitos puede de test-first.
adquisición de nuevas cuando el equipo todavía mentalidad de "escribir convertirse en una tarea
habilidades y prácticas. está adaptándose a esta código primero" a "una desafiante si no se cuenta
metodología. mentalidad de test-first". con los skills necesarios.
¿Cómo mejora TDD la calidad del software?
Reducción de defectos: Al escribir tests antes de
Red de seguridad: Las pruebas sirven como una
implementar el código funcional, TDD reduce la
red de seguridad que permite al equipo de
probabilidad de introducir defectos en el código
desarrollo realizar cambios o refactorizaciones en el
desde el principio. Esto se debe a que los criterios
código con la confianza de que cualquier regresión
de éxito de una función se definen antes de
o error introducido será capturado rápidamente por
implementarla, lo que reduce la ambigüedad y
los tests existentes.
mejora la precisión de los requisitos del software.
Enfoque iterativo incremental: El TDD fomenta un
enfoque iterativo e incremental, en el que la Documentación viva: Los tests actúan como una
enfoque iterativo e incremental
funcionalidad se construye y se prueba en forma de documentación viva que describe cómo se
pequeños incrementos. Así se garantiza que cada supone que debe comportarse el software. Esto es
parte del sistema se implemente y pruebe especialmente útil tanto para el mantenimiento del
correctamente antes de seguir adelante, sistema como para la incorporación de nuevos
reduciendo la complejidad y los riesgos asociados desarrolladores/ras, ya que pueden comprender
al desarrollo de grandes bloques. rápidamente las intenciones del código
consultando los tests.
Buenas Practicas
Claridad y limpieza: Los tests deben ser
Tests pequeños y focalizados: Cada test Denominación de los tests: Los nombres
claras y legibles, actuando como
debe centrarse en un único aspecto o de los tests deben ser descriptivos y reflejar
documentación viva del sistema. Deben
funcionalidad. Esto hace que los tests sean lo que están probando. Esto puede ayudar a
explicar el propósito y el uso esperado de las
más fáciles de escribir, entender y otros a entender el propósito de la prueba y
unidades de código para la comprensión y el
mantener. qué aspecto del código se está validando.
mantenimiento a largo plazo.
Refactorización: La refactorización no se
Frecuencia: Los tests deben ejecutarse tan
aplica solo al código de producción; los
a menudo como sea posible, idealmente de
tests también deben ser objeto de
forma automática mediante la integración
refactorización para mejorar su claridad y
continua, para proporcionar
eficiencia.
retroalimentación rápida sobre los cambios
en el código.
Buenas Practicas
Tests independientes: Cada test debe ser
independiente y no depender de otros. Esto asegura
que pueden ejecutarse en cualquier orden y que el
fallo de un test no afecta a los demás. Por ello, es Sencillez: Los tests deben ser simples y evitar
conveniente ejecutar todos los tests cuando se contener lógica condicional o bucles, ya que esto
añade un comportamiento nuevo (en la fase Green) puede introducir errores en los propios tests y
porque pasar el último test no significa que no hacerlos más difíciles de comprender y mantener.
exista un error en otra parte. De esta manera nos
aseguramos que no se ha introducido ningún error
de regresión.
Disciplina: Mantenerse fiel al ciclo de TDD (Red,
Green, Refactor) y resistir la tentación de saltarse Pair programming: Implementar TDD en parejas te
pasos o escribir código sin una prueba fallida ayuda a obtener feedback inmediato sobre los tests
previa. Esto asegura que el proceso de TDD se y su comportamiento. Al aplicar pair programming
aplicar pair programming
mantenga efectivo. mejorarás tus capacidades gracias al intercambio
positivo y constructivo de ideas.
Escuela de Chicago. También conocida como estilo clásico o
tradicional, propone un enfoque de adentro hacia afuera (inside-
out) y se centra en probar los comportamientos esperados del
software desde las partes más internas, o de dominio del sistema,
hacia las capas exteriores donde se produce la interacción con los
usuarios.
TDD - Ventajas: Es más directo y accesible para los nuevos practicantes
Chicago de TDD. Prioriza la simplicidad en el diseño desde el principio.
Desafíos: Puede resultar en un diseño menos enfocado en la
interfaz y más en la implementación, lo que a veces conduce a un
código menos modular y con mayor acoplamiento.
TDD - Londres
• Escuela de Londres. También conocida como estilo
Mockist, propone un desarrollo de afuera hacia
dentro (outside-in) y se centra en el diseño y la
arquitectura desde las capas exteriores de la
aplicación hasta las capas internas. En este tipo de
desarrollos se utilizan mocks y stubs para simular
las interacciones entre diferentes unidades de
código, lo que permite centrarse en cómo
interactúan las piezas del sistema entre sí, más que
en sus comportamientos individuales.
• En outside-in, normalmente se habla de un doble
ciclo: un primer test de aceptación y luego los
subsiguientes tests unitarios que se crean hasta
pasar el de aceptación (cada uno con su ciclo red-
green-refactor).
TDD - Londres
Ventajas: Promueve un Desafíos: Requiere una
diseño modular y comprensión más profunda
desacoplado, útil en de los conceptos de diseño
sistemas complejos donde de software y puede dar
la interacción entre lugar a una curva de
componentes es crítica. aprendizaje más elevada
Mocks y Stubs
UN MOCK es un objeto que simula el UN STUB es un objeto que reemplaza un
comportamiento de un objeto real en el componente real en el sistema y
sistema y permite verificar que ciertas devuelve respuestas predeterminadas
interacciones ocurren. Los mocks se cuando se llaman sus métodos. Los
utilizan principalmente para probar la stubs se utilizan principalmente para
interacción entre objetos, asegurándose proporcionar datos de prueba o
de que ciertos métodos se llamen con resultados de métodos que permitan
parámetros específicos o en un orden que la prueba continúe sin involucrar la
particular. lógica real del componente sustituido.
// Stub: Creamos una clase Logger que
la calculadora utilizará
class Logger {
public $mensajes = [];
public function log($message) {
Ejemplo del echo "LOG---".$message."<br>";
$this->mensajes[] = $message;
TDD //Guardar la informacion en un
archivo log
}
}
class Calculadora
private $logger ;
public function __construct($logger) {
$this->logger = $logger;
public function add($a, $b)
$result = $a + $b;
$this->logger->log("Add: $a + $b = $result"); // Aquí se llama al método log
Ejemplo del TDD }
return $result;
public function subtract($a, $b)
$result = $a - $b;
$this->logger->log("Subtract: $a - $b = $result"); // Aquí se llama al método
log
return $result;
}
• // Función para comparar valores esperados y reales
• function assertEquals($expected, $actual, $message) {
• if ($expected === $actual) {
• echo " $message VALIDO\n<br>";
Ejemplo del TDD
• } else {
• echo " $message FALLIDO: Se esperaba $expected pero se obtuvo $actual\n<br>";
• }
• }
•
// Test con Mock para la suma
function testAddConMock() {
// Mock del Logger
$mockLogger = new Logger();
$calculadora = new Calculadora($mockLogger);
$resultado = $calculadora->add(2, 3);
Ejemplo del TDD
assertEquals(5, $resultado, 'Test Suma: 2 +
3');
// Verificamos que el Logger haya registrado el
mensaje correcto
assertEquals('Add: 2 + 3 = 5', $mockLogger-
>mensajes[0], 'Mensaje de Logger en Suma');
}
•
// Test con Mock para la resta
function testSubtractConMock() {
// Mock del Logger
$mockLogger = new Logger();
$calculadora = new Calculadora($mockLogger);
$resultado = $calculadora->subtract(5, 3);
assertEquals(2, $resultado, 'Test Resta: 5 - 3');
Ejemplo del TDD // Verificamos que el Logger haya registrado el
mensaje correcto
assertEquals('Subtract: 5 - 3 = 2', $mockLogger-
>mensajes[0], 'Mensaje de Logger en Resta');
}
•
testAddConMock();
• testSubtractConMock();
Estrategias de
Despliegue
• El despliegue de aplicaciones
web implica mover una
aplicación desde el entorno de
desarrollo a un entorno donde
los usuarios finales puedan
acceder a ella. Existen varias
estrategias de despliegue que
deben considerarse:
Despliegue en Entornos de Desarrollo
• En este entorno, los desarrolladores
prueban nuevas funcionalidades y
cambios antes de lanzarlos a
producción. Aquí, se utilizan servidores
locales o configuraciones virtuales para
simular el entorno de producción. Este
despliegue es frecuente y rápido,
permitiendo iteraciones continuas.
Despliegue en Entornos de Producción
• Desplegar en producción requiere un
enfoque más cuidadoso para asegurar
que la aplicación sea estable y segura.
Se utilizan servidores robustos y
configuraciones optimizadas para
manejar grandes volúmenes de tráfico.
La automatización de este proceso,
utilizando herramientas como Ansible o
Jenkins, puede minimizar errores
humanos.
Despliegue en Plataforma como Servicio
(PaaS)
Servicios como Heroku, AWS
Elastic Beanstalk o Google App
Engine proporcionan
infraestructura y plataformas
gestionadas que simplifican el
despliegue y la administración
de aplicaciones. Los
desarrolladores pueden
enfocarse en el código, mientras
la plataforma maneja la
infraestructura subyacente.
Despliegue con
Contenedores
• Los contenedores, como
Docker, permiten
empaquetar una aplicación y
sus dependencias en un solo
contenedor portátil que
puede ejecutarse de manera
consistente en cualquier
entorno. Esto garantiza que
las aplicaciones funcionen de
la misma manera en
desarrollo, pruebas y
producción.
Integración Continua
• La integración continua (CI) es una
práctica que implica integrar cambios de
código en un repositorio central varias
veces al día. Cada integración se verifica
mediante la ejecución automática de
pruebas. Herramientas como Travis CI,
CircleCI o Jenkins ayudan a automatizar
este proceso, asegurando que el código
siempre esté en un estado de entrega.
Despliegue
Continuo
• El despliegue continuo (CD)
extiende la integración continua
mediante la automatización del
despliegue de la aplicación en
producción. Esto permite que las
nuevas versiones se lancen
rápidamente y con menos errores,
proporcionando a los usuarios
finales acceso a las últimas
funcionalidades y correcciones.
Herramientas de CD monitorean el
estado de la aplicación y pueden
realizar rollbacks automáticos en
caso de fallos.