# Bloque 3 · Tema 9
# Repositorios: estructura y actualización. Generación de código y documentación. Metodologías de desarrollo. Pruebas. Programas para control de versiones. Plataformas de desarrollo colaborativo de software.

---

# 1. Esquema introductorio (visión rápida)

**Control de versiones**
→ Sistema que registra los cambios en el código a lo largo del tiempo.

**Tipos de repositorios**
- Locales, centralizados (SVN), distribuidos (Git)

**Metodologías de desarrollo**
- Tradicionales: cascada, modelo en V, espiral, RUP
- Ágiles: Scrum, Kanban, XP

**Pruebas de software**
- Unitarias, integración, sistema, aceptación (UAT)
- Caja blanca vs. caja negra vs. caja gris
- Pirámide de pruebas: unitarias → integración → E2E
- TDD (Red → Green → Refactor) y BDD (Given-When-Then)

**Plataformas colaborativas**
- GitHub (Microsoft, 2018), GitLab (on-premise), Bitbucket (Atlassian)

**Conceptos transversales**
- CI/CD: integración, entrega y despliegue continuos
- SemVer: MAJOR.MINOR.PATCH
- .gitignore, hooks, protección de ramas, Pull Request

---

# 2. Repositorios: concepto y estructura

## 2.1 Qué es un repositorio

Un **repositorio** (*repository* o *repo*) es un almacén centralizado o distribuido donde se guarda el código fuente y el historial completo de todos los cambios realizados sobre él.

Un repositorio no solo almacena el estado actual del código: actúa como una **base de datos de cambios** que permite conocer quién modificó qué, cuándo y por qué. Esto hace posible colaborar en equipo, revertir errores y gestionar versiones paralelas.

Contiene:
- El **árbol de trabajo** (*working tree*): los archivos actuales del proyecto.
- El **historial de commits**: cada instantánea del proyecto en el tiempo.
- Las **ramas** (*branches*): líneas de desarrollo paralelas e independientes.
- Las **etiquetas** (*tags*): marcas inmutables en commits concretos (versiones de release).
- Los **metadatos** del sistema de control de versiones.

## 2.2 Tipos de repositorios

### Repositorio local
- Existe solo en el equipo del desarrollador.
- Sin historial compartido ni colaboración directa.
- Adecuado solo para proyectos personales sin colaboradores.

### Repositorio centralizado (VCS centralizado)
- Un único servidor central almacena todo el historial.
- Los desarrolladores hacen *checkout* del servidor para obtener los archivos; solo guardan los ficheros en local, **no el historial**.
- Ejemplos: **SVN (Subversion)**, **CVS (Concurrent Versions System)**.
- **Desventaja principal:** punto único de fallo; si el servidor no está disponible, nadie puede consultar el historial ni confirmar cambios.

### Repositorio distribuido (DVCS)
- Cada desarrollador tiene una **copia completa del repositorio**, incluyendo todo el historial.
- Se puede trabajar sin conexión al servidor remoto.
- Ejemplos: **Git**, **Mercurial**.
- **Ventajas:** sin punto único de fallo, operaciones locales muy rápidas, flujos de trabajo muy flexibles.

## 2.3 Estructura de un repositorio Git

El directorio `.git/` es el núcleo del repositorio. La estructura completa es:

```
proyecto/
├── .git/                  ← Directorio oculto con todos los metadatos de Git
│   ├── HEAD               ← Referencia a la rama activa actualmente
│   ├── config             ← Configuración local del repositorio
│   ├── hooks/             ← Scripts ejecutados en eventos (pre-commit, post-merge…)
│   ├── objects/           ← Almacén de objetos: blobs, trees, commits, tags
│   │   └── pack/          ← Objetos empaquetados (packfiles) para mayor eficiencia
│   ├── refs/
│   │   ├── heads/         ← Ramas locales
│   │   ├── remotes/       ← Ramas remotas (origin/main, origin/develop…)
│   │   └── tags/          ← Etiquetas
│   └── index              ← Área de staging (índice)
├── src/
├── tests/
├── .gitignore             ← Patrones de archivos excluidos del control de versiones
└── README.md
```

### El archivo .gitignore

El archivo `.gitignore` define qué archivos y directorios debe ignorar Git. Es una práctica fundamental para excluir del repositorio lo que no debe versionarse:

```
# Dependencias externas
node_modules/
target/
build/

# Entornos y configuraciones locales
.env
*.env.local
application-local.properties

# Compilados y ejecutables
*.class
*.jar
*.war

# Carpetas de IDEs
.idea/
.vscode/
*.iml
```

## 2.4 Objetos internos de Git

Git es un **sistema de almacenamiento de contenido direccionable**: cada objeto se identifica de forma única por el **hash SHA-1** (40 caracteres hexadecimales) calculado sobre su contenido. Si el contenido cambia, el hash cambia, lo que garantiza la **integridad** del historial.

| Objeto | Descripción |
|--------|-------------|
| **blob** | Contenido bruto de un archivo (sin nombre ni ruta, solo contenido) |
| **tree** | Directorio: lista de blobs y otros trees con sus nombres y permisos de acceso |
| **commit** | Instantánea + autor + fecha + mensaje + referencia al commit padre (o padres en un merge) |
| **tag** | Referencia con nombre a un commit concreto; los tags anotados incluyen autor, fecha y mensaje propio |

Git modela el historial como un **grafo acíclico dirigido (DAG)** de commits, donde cada commit apunta hacia atrás a su padre o padres. Esto garantiza que el historial sea inmutable e íntegro. Con el tiempo, los objetos sueltos se agrupan en **packfiles** comprimidos para ahorrar espacio en disco.

---

# 3. Control de versiones con Git

## 3.1 Áreas de trabajo en Git

```
Working Directory → Staging Area (index) → Repositorio local → Repositorio remoto
      (editar)           (git add)            (git commit)          (git push)
```

| Área | Descripción |
|------|-------------|
| **Working directory** | Archivos que ves y editas |
| **Staging area** | Archivos preparados para el próximo commit |
| **Repositorio local** | Historial de commits almacenado en `.git/` |
| **Repositorio remoto** | Copia alojada en un servidor (GitHub, GitLab…) |

El **staging area** es el elemento diferencial de Git: permite seleccionar qué cambios concretos incluir en cada commit, obteniendo un historial limpio y preciso sin necesidad de incluir todo lo modificado a la vez.

## 3.2 Comandos principales de Git

```bash
# Configuración inicial
git config --global user.name  "Nombre Apellido"
git config --global user.email "email@ejemplo.com"
git config --global core.editor "code --wait"   # editor por defecto

# Iniciar repositorio
git init                    # nuevo repo local en el directorio actual
git clone URL               # clonar repo remoto (crea directorio local)
git clone URL mi-carpeta    # clonar en un directorio con nombre concreto

# Ciclo básico
git status                  # ver estado de los archivos
git diff                    # cambios en working directory vs staging
git diff --staged           # cambios en staging vs último commit
git add archivo.py          # añadir un archivo concreto al staging
git add .                   # añadir todos los cambios al staging
git add -p                  # añadir de forma interactiva (por fragmentos)
git commit -m "mensaje"     # crear commit con mensaje en línea
git commit --amend          # modificar el último commit (mensaje o contenido)
git log --oneline --graph   # historial compacto con grafo de ramas

# Ramas
git branch                  # listar ramas locales
git branch -a               # listar ramas locales y remotas
git branch nueva-rama       # crear rama en el commit actual
git checkout nueva-rama     # cambiar a una rama existente
git checkout -b nueva-rama  # crear rama y cambiar a ella (shortcut)
git switch nueva-rama       # cambiar de rama (comando moderno)
git switch -c nueva-rama    # crear y cambiar (comando moderno)
git merge otra-rama         # fusionar otra-rama en la rama activa
git branch -d rama          # eliminar rama (solo si ya está mergeada)
git branch -D rama          # eliminar rama forzosamente

# Repositorio remoto
git remote -v               # ver remotos configurados
git remote add origin URL   # vincular repositorio remoto como 'origin'
git push origin main        # subir rama main al remoto
git push -u origin main     # subir y establecer upstream (tracking)
git pull origin main        # descargar y fusionar cambios del remoto
git fetch origin            # descargar cambios sin fusionar

# Etiquetas
git tag                     # listar etiquetas
git tag v1.0.0              # etiqueta ligera en el commit actual
git tag -a v1.0.0 -m "Versión estable 1.0.0"  # etiqueta anotada
git push origin --tags      # subir todas las etiquetas al remoto
git push origin v1.0.0      # subir una etiqueta concreta

# Deshacer y reescribir historial
git revert HASH             # crear nuevo commit que deshace el commit indicado
git reset --soft HEAD~1     # deshacer último commit, mantener cambios en staging
git reset --mixed HEAD~1    # deshacer último commit, pasar cambios a working dir
git reset --hard HEAD~1     # deshacer último commit y descartar cambios (¡destructivo!)
git stash                   # guardar cambios no commiteados en una pila temporal
git stash list              # listar todos los stashes guardados
git stash pop               # recuperar y eliminar el último stash
git stash apply stash@{2}   # aplicar un stash concreto sin eliminarlo
```

## 3.3 Flujos de trabajo (workflows) con Git

### Gitflow
Workflow estructurado con ramas de larga duración para proyectos con ciclos de release bien definidos:
- `main` – código en producción, siempre estable y etiquetado.
- `develop` – rama de integración de features.
- `feature/*` – nuevas funcionalidades (se crean desde `develop`, se mergean a `develop`).
- `release/*` – preparación de versión (correcciones menores, bump de versión).
- `hotfix/*` – correcciones urgentes en producción (se crean desde `main`, se mergean a `main` y `develop`).

### GitHub Flow / Trunk-Based Development
- Solo existe `main` como rama principal de larga duración.
- Las ramas de feature son de corta duración (horas o días).
- Pull Request → revisión de código → CI en verde → merge a main.
- Ideal para despliegue continuo: cada merge a main puede activar un despliegue a producción.

### Resolución de conflictos
Un conflicto ocurre cuando dos ramas modifican las mismas líneas de un archivo. Git marca el conflicto y el desarrollador debe resolverlo manualmente:
```
<<<<<<< HEAD
  código de la rama activa actualmente
=======
  código de la rama que se está fusionando
>>>>>>> otra-rama
```
Tras resolver, se eliminan los marcadores y se confirma un commit de resolución.

## 3.4 Merge vs. Rebase

| Operación | Resultado en el historial | Cuándo usarla |
|-----------|--------------------------|---------------|
| **merge** | Crea un commit de merge; conserva el historial tal como ocurrió | Para integrar ramas de larga duración; preserva el historial real |
| **rebase** | Reaplica los commits sobre una nueva base; historial lineal | Para limpiar el historial de una feature branch antes del merge |
| **merge --squash** | Comprime todos los commits de la rama en uno solo | Para mantener `main` con un historial muy limpio |

> **Regla de oro del rebase:** nunca se deben rebasear commits que ya han sido publicados en un repositorio compartido, ya que reescribe el historial y puede romper el trabajo de otros desarrolladores.

## 3.5 Comandos avanzados de Git

```bash
# Rebase
git rebase main                 # reaplica los commits de la rama actual sobre main
git rebase -i HEAD~3            # rebase interactivo de los últimos 3 commits
                                # (permite squash, reorder, editar mensajes, drop)

# Cherry-pick: aplica un commit concreto de otra rama a la rama activa
git cherry-pick HASH            # aplica el commit indicado
git cherry-pick A..B            # aplica el rango de commits de A a B

# Bisect: búsqueda binaria para encontrar el commit que introdujo un bug
git bisect start
git bisect bad                  # el commit actual contiene el bug
git bisect good v1.0.0          # este commit funcionaba correctamente
# Git hace checkout de commits intermedios hasta localizar el culpable
git bisect reset                # terminar la sesión de bisect

# Blame: ver quién modificó cada línea de un archivo y en qué commit
git blame archivo.py

# Reflog: historial local de movimientos de HEAD (para recuperar commits perdidos)
git reflog
git checkout HEAD@{5}           # ir a un estado anterior del repositorio
```

---

# 4. Generación de código y documentación

## 4.1 Generación de código

### Herramientas de generación
| Herramienta | Descripción |
|-------------|-------------|
| **Scaffolding** | Genera estructura inicial del proyecto (Angular CLI, Spring Initializr, create-react-app) |
| **ORM / generadores de mapeo** | Genera clases desde el esquema de BD (Hibernate, Entity Framework, JPA) |
| **Generadores de API** | Genera código cliente y servidor desde especificación OpenAPI/Swagger |
| **Compiladores / transpiladores** | TypeScript → JavaScript, SASS/LESS → CSS, Kotlin → JVM bytecode |
| **Plantillas (templates)** | Freemarker, Thymeleaf, Mustache, Jinja2 |
| **Linters y formatters** | ESLint, Prettier, Checkstyle, Black; garantizan calidad y estilo homogéneo |

### Integración Continua (CI) y Entrega Continua (CD)
- **CI (Continuous Integration):** cada push activa automáticamente la compilación, análisis de código y ejecución de pruebas. Detecta errores de integración en minutos.
- **CD (Continuous Delivery):** el artefacto resultado está siempre listo para desplegar; el despliegue final puede requerir aprobación manual.
- **CD (Continuous Deployment):** cada cambio validado se despliega automáticamente en producción sin intervención humana.

Herramientas: **Jenkins**, **GitHub Actions**, **GitLab CI/CD**, **Azure DevOps**, Travis CI, CircleCI.

### Fases típicas de un pipeline CI/CD

```
Commit → Build → Static Analysis → Unit Tests → Integration Tests → Security Scan
       → Package → Deploy Staging → Acceptance Tests → Deploy Production
```

| Fase | Herramientas habituales |
|------|------------------------|
| Build | Maven, Gradle, npm, Make |
| Static analysis | SonarQube, ESLint, Checkstyle |
| Unit tests | JUnit, pytest, Jest |
| Integration tests | TestContainers, Postman/Newman |
| Security scan | OWASP Dependency-Check, Snyk, Trivy |
| Package | Docker, JAR/WAR |
| Deploy | Kubernetes, Ansible, Terraform |

## 4.2 Documentación del código

### Javadoc (Java)
```java
/**
 * Calcula el área de un círculo.
 *
 * @param radio El radio del círculo (debe ser positivo).
 * @return El área calculada en unidades cuadradas.
 * @throws IllegalArgumentException si el radio es negativo.
 * @since 1.0
 * @see Math#PI
 */
public double calcularArea(double radio) {
    if (radio < 0) throw new IllegalArgumentException("Radio negativo");
    return Math.PI * radio * radio;
}
```

### Docstrings (Python)
```python
def calcular_area(radio: float) -> float:
    """
    Calcula el área de un círculo.

    Args:
        radio: El radio del círculo (debe ser positivo).
    Returns:
        El área calculada en unidades cuadradas.
    Raises:
        ValueError: Si el radio es negativo.
    Example:
        >>> calcular_area(5.0)
        78.53981633974483
    """
```

### Herramientas de documentación
| Herramienta | Lenguaje / Ámbito |
|-------------|------------------|
| **Javadoc** | Java – genera HTML desde comentarios `/** */` |
| **Sphinx / pdoc** | Python – admite reStructuredText y Markdown |
| **JSDoc** | JavaScript / TypeScript |
| **Doxygen** | C, C++, y otros lenguajes |
| **Swagger / OpenAPI** | APIs REST – documentación interactiva |
| **ReadTheDocs** | Publicación de documentación técnica online |
| **MkDocs / AsciiDoc** | Documentación de proyectos en general |

## 4.3 Versionado semántico (SemVer)

El versionado semántico, definido en **semver.org**, establece un formato `MAJOR.MINOR.PATCH`:

| Campo | Cuándo se incrementa |
|-------|---------------------|
| **MAJOR** | Cambio incompatible con la API anterior (*breaking change*) |
| **MINOR** | Nueva funcionalidad compatible hacia atrás |
| **PATCH** | Corrección de errores compatible hacia atrás |

Ejemplos:
- `1.0.0` → primera versión estable.
- `1.1.0` → nueva funcionalidad sin romper nada.
- `1.1.1` → corrección de un bug.
- `2.0.0` → cambio de API incompatible con la versión 1.x.
- `1.0.0-beta.1` → pre-release (alpha, beta, rc).

El **CHANGELOG.md** documenta qué cambia entre versiones. Su mantenimiento es una buena práctica fundamental en proyectos open source y corporativos.

---

# 5. Metodologías de desarrollo de software

## 5.1 Metodologías tradicionales (predictivas)

### Cascada (Waterfall)
Fases secuenciales y sin solapamiento. Cada fase debe completarse antes de iniciar la siguiente:

1. Requisitos → 2. Análisis → 3. Diseño → 4. Implementación → 5. Pruebas → 6. Despliegue → 7. Mantenimiento

**Ventajas:** sencilla de gestionar, documentación exhaustiva, adecuada para proyectos con requisitos estables y bien conocidos desde el inicio.  
**Inconvenientes:** extremadamente inflexible ante cambios; los errores de análisis se descubren en la fase de pruebas, lo que los hace muy costosos de corregir.

### Modelo en V
Extiende la cascada asociando simétricamente cada fase de desarrollo con su fase de pruebas correspondiente. Las pruebas se planifican en paralelo al diseño, no al final:

```
Requisitos del sistema     ←→   Pruebas de aceptación (UAT)
   Diseño del sistema      ←→   Pruebas del sistema
  Diseño de componentes    ←→   Pruebas de integración
        Codificación        →   Pruebas unitarias
```

**Ventaja clave frente a cascada:** las pruebas se diseñan desde el principio, no como una actividad de última hora.

### Modelo en Espiral (Boehm, 1986)
Combina iteración con **análisis de riesgos** en cada ciclo. Cada vuelta de la espiral consta de cuatro cuadrantes:
1. **Planificación:** objetivos, restricciones, alternativas.
2. **Análisis de riesgos:** identificación y mitigación de riesgos técnicos.
3. **Ingeniería:** desarrollo y pruebas del incremento del ciclo.
4. **Evaluación del cliente:** revisión del incremento y planificación de la siguiente espiral.

Adecuado para proyectos grandes con incertidumbre significativa.

### RUP (Rational Unified Process)
- Iterativo, incremental y orientado a la arquitectura.
- **4 fases:** Inicio (*Inception*), Elaboración (*Elaboration*), Construcción (*Construction*), Transición (*Transition*).
- Cada fase contiene varias iteraciones con entregables definidos.
- Usa **artefactos UML** (diagramas de clases, secuencia, casos de uso, etc.).
- Muy orientado a proyectos empresariales grandes y complejos.

## 5.2 Metodologías ágiles

El **Manifiesto Ágil (2001)** fue firmado por 17 expertos y establece **4 valores** y 12 principios:

- Individuos e interacciones **por encima de** procesos y herramientas.
- Software funcionando **por encima de** documentación exhaustiva.
- Colaboración con el cliente **por encima de** negociación de contratos.
- Respuesta al cambio **por encima de** seguir un plan.

> Importante: el Manifiesto no dice que los elementos de la derecha no tengan valor; dice que los de la izquierda se valoran **más**.

### Scrum

| Elemento | Descripción |
|----------|-------------|
| **Sprint** | Iteración de 1-4 semanas con entregable potencialmente funcional |
| **Product Backlog** | Lista priorizada de todas las funcionalidades del producto |
| **Sprint Backlog** | Tareas del sprint actual seleccionadas del Product Backlog |
| **Incremento** | Resultado de cada sprint: software funcional que cumple la DoD |
| **Sprint Planning** | Reunión de inicio del sprint: selección y descomposición de tareas |
| **Daily Scrum** | Reunión diaria de 15 min: ¿qué hice ayer? ¿qué haré hoy? ¿impedimentos? |
| **Sprint Review** | Demostración del incremento al cliente al final del sprint |
| **Sprint Retrospective** | Reflexión del equipo sobre el proceso: qué mejorar en el siguiente sprint |
| **Product Owner (PO)** | Representa al cliente; gestiona y prioriza el Product Backlog |
| **Scrum Master (SM)** | Facilita el proceso, elimina impedimentos, protege al equipo |
| **Development Team** | Equipo autogestionado y multifuncional que desarrolla el producto |

**Métricas de Scrum:**
- **Velocity:** story points completados por sprint; mide la capacidad del equipo y sirve para prever entregas.
- **Burn-down chart:** gráfica que muestra el trabajo restante en el sprint día a día; permite detectar desviaciones.
- **Definition of Done (DoD):** criterios acordados que debe cumplir un incremento para considerarse terminado.
- **Definition of Ready (DoR):** criterios que debe cumplir un ítem del backlog para poder entrar en un sprint.

### Kanban
- Visualización del trabajo en un **tablero** con columnas que representan los estados: Pendiente / En progreso / Revisión / Hecho.
- **Límite WIP (Work In Progress):** número máximo de tareas simultáneas por columna; reduce el multitasking y mejora el flujo.
- Sin sprints fijos: el trabajo fluye de forma continua.
- Métricas clave: **lead time** (tiempo desde que se solicita hasta que se entrega) y **cycle time** (tiempo desde que se empieza hasta que se entrega).
- Muy adecuado para equipos de mantenimiento, soporte y operaciones.

### XP (Extreme Programming)
Conjunto de prácticas técnicas intensas orientadas a la calidad del código:
- **TDD** (Test-Driven Development): los tests se escriben antes que el código.
- **Pair programming:** dos desarrolladores comparten pantalla y teclado.
- **Integración continua:** los cambios se integran varias veces al día.
- **Refactoring continuo:** el código se mejora constantemente sin añadir funcionalidad.
- **Diseño simple y YAGNI** (You Ain't Gonna Need It): no implementar lo que no se necesita aún.

### Comparativa de metodologías

| | Cascada | Modelo en V | Scrum | Kanban | XP |
|-|---------|-------------|-------|--------|----|
| Planificación | Fija al inicio | Fija al inicio | Por sprint | Continua | Por iteración |
| Cambios | Muy difíciles | Muy difíciles | Cada sprint | En cualquier momento | Bienvenidos |
| Documentación | Extensa | Extensa | Mínima necesaria | Mínima | Mínima |
| Pruebas | Al final | Paralelas al diseño | Continuas | Continuas | Antes del código (TDD) |
| Adecuado para | Requisitos estables | Sistemas críticos | Proyectos con cambios | Mantenimiento / flujo | Equipos pequeños, alta calidad técnica |

---

# 6. Pruebas de software

## 6.1 Objetivos de las pruebas

- Detectar defectos (*bugs*) lo antes posible.
- **Verificar** que el software está construido correctamente según el diseño.
- **Validar** que el software satisface las necesidades reales del usuario.
- Aumentar la confianza en la calidad del producto.
- Proporcionar información para la toma de decisiones de release.

> **Verificación:** ¿estamos construyendo el sistema correctamente? (conforme a la especificación)  
> **Validación:** ¿estamos construyendo el sistema correcto? (conforme a la necesidad del usuario)

## 6.2 Niveles de prueba

### Pruebas unitarias (Unit Testing)
- Prueban la **unidad mínima de código** (función, método, clase) de forma **aislada**.
- Se usan **mocks** y **stubs** para simular dependencias externas (bases de datos, servicios, APIs).
- Son las más rápidas de ejecutar y deben ser las más numerosas (base de la pirámide de pruebas).
- Herramientas: **JUnit 5** (Java), **Mockito** (mocks Java), **pytest** (Python), **Jest** (JavaScript).

### Pruebas de integración
- Verifican que varios módulos o componentes funcionan correctamente **juntos**.
- Detectan problemas de interfaz entre módulos (formato de datos incorrecto, errores de comunicación).
- Herramientas: **TestContainers**, **Spring Boot Test**, **Postman/Newman**.

### Pruebas de sistema
- Prueban el **sistema completo integrado** en un entorno similar a producción.
- Verifican el comportamiento frente a los requisitos funcionales y no funcionales (rendimiento, seguridad, usabilidad).

### Pruebas de aceptación (UAT – User Acceptance Testing)
- Realizadas por el **usuario final o cliente**.
- Confirman que el sistema cumple los requisitos del negocio y está listo para producción.
- Criterio de finalización: **DoD** (Definition of Done).
- En metodologías ágiles pueden automatizarse mediante **BDD** (Behavior-Driven Development).

## 6.3 Técnicas de prueba

### Caja negra (Black-box Testing)
- No se conoce (o no importa) la implementación interna.
- Se prueba la **funcionalidad**: entradas → salidas esperadas.
- Técnicas: particiones de equivalencia, valores límite, tablas de decisión, pruebas basadas en estado.

### Caja blanca (White-box / Glass-box Testing)
- Se conoce y analiza el **código fuente interno**.
- Se persigue cubrir el máximo de rutas de ejecución del código.
- Métricas de cobertura:
  - **Cobertura de líneas** (*line coverage*): % de líneas ejecutadas por los tests.
  - **Cobertura de ramas** (*branch coverage*): % de ramas condicionales (if/else) cubiertas.
  - **Cobertura de caminos** (*path coverage*): % de caminos posibles de ejecución (la más completa y costosa).
- Herramientas de cobertura: **JaCoCo** (Java), **Istanbul/nyc** (JavaScript), **coverage.py** (Python).

### Caja gris (Grey-box Testing)
- Combinación de caja negra y caja blanca.
- Se conoce la estructura interna pero las pruebas se diseñan desde la perspectiva del usuario.

## 6.4 Tipos de pruebas por objetivo

| Tipo | Qué verifica |
|------|-------------|
| **Pruebas de regresión** | Que los cambios nuevos no rompen funcionalidad existente; se automatizan en CI |
| **Pruebas de rendimiento / carga** | Comportamiento bajo alta demanda (JMeter, Gatling, k6) |
| **Pruebas de estrés** | Comportamiento al superar la capacidad máxima del sistema |
| **Pruebas de seguridad (Pen Testing)** | Vulnerabilidades explotables (OWASP ZAP, Burp Suite) |
| **Pruebas de usabilidad** | Facilidad de uso para el usuario final |
| **Pruebas de accesibilidad** | Cumplimiento de estándares WCAG 2.1 |
| **Smoke testing** | Verificación rápida de que las funciones básicas del sistema arrancan correctamente |
| **Pruebas E2E (End-to-End)** | Flujo completo de usuario simulando el navegador (Selenium, Cypress, Playwright) |
| **Pruebas de mutación** | Modifican el código para verificar que los tests detectan los cambios (PIT, Stryker) |

## 6.5 TDD – Test Driven Development

Ciclo **Red → Green → Refactor**:
1. **Red:** escribir un test que falle porque la funcionalidad no existe aún. Debe fallar por el motivo correcto.
2. **Green:** escribir el código **mínimo** para que el test pase. No importa que sea provisional.
3. **Refactor:** mejorar el diseño y la legibilidad del código sin que fallen los tests existentes.

**Ventajas:** código más simple y desacoplado, alto nivel de cobertura desde el inicio, los tests actúan como documentación viva del comportamiento esperado.

## 6.6 BDD – Behavior Driven Development

Extensión del TDD que describe el comportamiento del sistema en **lenguaje natural** comprensible por el cliente, usando la sintaxis **Given-When-Then**:

```gherkin
Feature: Autenticación de usuario

  Scenario: Login correcto
    Given el usuario "ana" existe en el sistema
    When intenta iniciar sesión con la contraseña correcta
    Then debe acceder al panel de control
    And ver el mensaje "Bienvenida, Ana"

  Scenario: Login con contraseña incorrecta
    Given el usuario "ana" existe en el sistema
    When intenta iniciar sesión con contraseña incorrecta
    Then debe ver el mensaje "Credenciales incorrectas"
```

Herramientas: **Cucumber** (Java/Ruby/JavaScript), **Behave** (Python), **SpecFlow** (.NET).

## 6.7 Pirámide de pruebas

La pirámide de pruebas (Mike Cohn) define la proporción ideal de cada tipo de prueba:

```
         /\
        /  \       ← E2E / UI Tests  (pocas, lentas, más frágiles)
       /----\
      /      \     ← Integration Tests (algunas, velocidad media)
     /--------\
    /          \   ← Unit Tests       (muchas, rápidas, económicas)
   /____________\
```

- **Base (Unit):** mayor número, ejecución en milisegundos, coste bajo, aisladas de infraestructura.
- **Medio (Integration):** número moderado, requieren infraestructura, ejecución en segundos.
- **Cima (E2E / UI):** pocas, ejecución en minutos, más frágiles y caras de mantener.

El antipatrón contrario se llama **pirámide invertida** o **cono de helado**: muchas pruebas de UI y pocas unitarias → suite lenta, frágil y cara.

---

# 7. Plataformas de desarrollo colaborativo

## 7.1 GitHub

- Mayor plataforma mundial de alojamiento de código Git.
- Propiedad de **Microsoft** (adquirida en 2018).
- **Pull Request (PR):** mecanismo principal de colaboración; propuesta de cambios para revisión y discusión antes de mergear.
- **Issues:** gestión de tareas, bugs, mejoras y discusiones del proyecto.
- **GitHub Actions:** CI/CD integrado mediante ficheros YAML en `.github/workflows/`.
- **GitHub Pages:** alojamiento gratuito de sitios estáticos directamente desde el repositorio.
- **GitHub Copilot:** asistente de código basado en IA (Large Language Model).
- **GitHub Codespaces:** entorno de desarrollo completo en la nube, accesible desde el navegador.
- **GitHub Packages:** registro de artefactos (npm, Maven, Docker, etc.) integrado.
- **Dependabot:** bot que detecta dependencias vulnerables y propone actualizaciones automáticas.
- **CodeQL y Secret Scanning:** análisis de seguridad integrado en el repositorio.

## 7.2 GitLab

- Disponible como **SaaS** (gitlab.com) y como instalación **on-premise** en servidores propios.
- **CI/CD nativo** muy completo, configurado mediante el fichero `.gitlab-ci.yml`.
- Pipeline con stages (build, test, deploy) y environments (staging, production).
- **Container Registry** integrado para imágenes Docker.
- **GitLab Pages** para publicar documentación o sitios estáticos.
- Gestión de proyectos completa: wikis, tableros Kanban, milestones y epics.
- **Muy usado en la Administración Pública y entornos corporativos** por ofrecer control total del código mediante despliegue on-premise.

## 7.3 Bitbucket

- Propiedad de **Atlassian** (misma empresa que Jira y Confluence).
- Integración nativa con **Jira** para vincular commits y Pull Requests a tareas del proyecto.
- **Bitbucket Pipelines:** CI/CD integrado, configurado con `bitbucket-pipelines.yml`.
- Compatible originalmente con Git y Mercurial (Mercurial fue descontinuado en 2020).
- Muy usado en entornos empresariales con el ecosistema Atlassian completo (Jira + Confluence + Bitbucket).

## 7.4 Otras herramientas del ciclo de vida

| Herramienta | Tipo | Descripción |
|-------------|------|-------------|
| **Jira** | Gestión de proyectos | Seguimiento de tareas, sprints, backlog, tableros Kanban/Scrum |
| **Confluence** | Documentación | Wiki corporativa integrada con Jira |
| **SonarQube** | Calidad de código | Análisis estático: code smells, cobertura, vulnerabilidades, duplicaciones |
| **Jenkins** | CI/CD | Servidor de automatización open-source; altamente extensible con plugins |
| **Docker Hub** | Registro de contenedores | Repositorio de imágenes Docker públicas y privadas |
| **Nexus / Artifactory** | Repositorios de artefactos | Maven, npm, Docker, Helm charts; proxy de dependencias externas |
| **Azure DevOps** | Suite DevOps completa | Repos, Boards, Pipelines, Artifacts, Test Plans; integrado con Azure |

## 7.5 Funcionalidades colaborativas clave

| Función | Descripción |
|---------|-------------|
| **Fork** | Copia independiente de un repositorio en tu cuenta; base del modelo open source |
| **Pull Request / Merge Request** | Solicitud para integrar cambios tras revisión y aprobación |
| **Code review** | Revisión del código por otro/s desarrolladores antes de mergear |
| **Branch protection** | Impide push directo a ramas protegidas (main, develop); obliga a PR y CI en verde |
| **Webhooks** | Notificaciones HTTP automáticas a servicios externos ante cada evento (push, PR…) |
| **Wiki** | Documentación del proyecto integrada en la plataforma |
| **Milestones** | Agrupación de issues y PRs para seguimiento de versiones o fechas de entrega |
| **Labels / etiquetas** | Clasificación de issues y PRs: bug, enhancement, documentation… |

---

# 8. Resumen: conceptos clave para el examen

| Concepto | Dato clave |
|----------|-----------|
| DVCS | Control de versiones distribuido; cada clon tiene el historial completo |
| Git | DVCS más usado; objetos SHA-1; historial en forma de DAG |
| Commit | Instantánea identificada por hash SHA-1; apunta a su(s) padre(s) |
| Branch | Línea de desarrollo paralela; `main` es la rama principal por convención |
| Merge vs Rebase | Merge preserva el historial real; Rebase lo lineariza (no rebasear commits publicados) |
| Gitflow | main + develop + feature/* + release/* + hotfix/* |
| .gitignore | Archivo que define qué ficheros excluir del control de versiones |
| CI/CD | CI: integración continua; CD: entrega/despliegue continuo (Jenkins, Actions, GitLab CI) |
| SemVer | MAJOR.MINOR.PATCH; MAJOR = breaking change, MINOR = nueva feature, PATCH = bugfix |
| Cascada | Fases secuenciales sin retroceso; errores se detectan tarde |
| Modelo en V | Cascada + pruebas planificadas simétricamente desde el diseño |
| Manifiesto Ágil | 2001; 4 valores: individuos, software funcionando, colaboración, respuesta al cambio |
| Scrum | Sprints 1-4 semanas; PO, SM, Dev Team; Planning, Daily, Review, Retrospective |
| Velocity | Story points completados por sprint; mide capacidad del equipo |
| DoD | Definition of Done: criterios de terminado de un incremento en Scrum |
| Kanban | Tablero visual, límites WIP; métricas: lead time y cycle time |
| TDD | Red → Green → Refactor; el test se escribe antes que el código |
| BDD | Given-When-Then; comportamiento en lenguaje natural; Cucumber, Behave |
| Prueba unitaria | Unidad mínima de forma aislada; mocks/stubs para dependencias |
| Prueba de integración | Varios módulos juntos; detecta problemas de interfaz |
| Prueba de aceptación (UAT) | La realiza el usuario final; criterio: DoD |
| Caja negra | Funcionalidad sin ver el código; particiones de equivalencia, valores límite |
| Caja blanca | Conociendo el código; cobertura de líneas, ramas y caminos |
| Pirámide de pruebas | Base: unitarias (muchas); medio: integración; cima: E2E (pocas) |
| Pull Request | Propuesta de cambios para revisión antes de mergear |
| GitHub | Plataforma más popular; Microsoft (2018); Actions para CI/CD; Copilot IA |
| GitLab | On-premise; muy usada en Administración Pública; CI/CD con .gitlab-ci.yml |
| Bitbucket | Atlassian; integración nativa con Jira |
| SonarQube | Análisis estático de calidad del código: code smells, cobertura, vulnerabilidades |
