La wiki de TempWin

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
===== Notas sobre el curso de Laravel 8 =====

[[informatica:programacion:php:cursos:laravel_8|Curso de Laravel 8.0]]

  * XtremeProgramming
    * Pair programming: dos programando
    * Mob programming: uno programa (navigator¿?), otro dirige (driver¿?)

Grupo 1:

  * Santiago Platero Delgado
  * Carlos Díaz Fajardo
  * Carlos Javier

Metodología ágil: nadie conoce el futuro, a currar hasta entonces.

Probamos funcionalidad / comportamiento, no valores.

Primer test, ponerlo en verde, programar la función. Continuar al siguiente test.

Empresas de alumnos:

  * Minsait
  * Altia
  * Coremain
  * AVA
  * Coremain
  * Tragsatec

==== Kata ====

  * https://kata-log.rocks/mars-rover-kata

==== Kata Fizz Buzz ====

  * https://kata-log.rocks/fizz-buzz-kata

Base de partida:

<code php>
use PHPUnit\Framework\TestCase;

class DefaultTest extends Testcase {

    public function xxx() {
    
       // Arrange
       // Act
       // Assert
    }
}
</code>

Mejora 1:

<code php>
use PHPUnit\Framework\TestCase;

class DefaultTest extends Testcase {

    /** @test */
    public function Given_a_number_When_translate_Then_returns_same_number() {
    
       // Arrange
       $sut = new FizzBuzzTranslator();
       
       // Act
       $response = $sut->translate(2);
       
       // Assert
       $this->assertSame(2, $response);
    }
}
</code>

Si no ponemos "@test", tendríamos que empezar cada función de test por ''test_''

Terminología:

  * corner case: casos que límite que podrían fallan o no están contemplados inicialmente
  * happy path: el camino más fácil.
  * zombie testing: acuérdate de probar [[https://hackernoon.com/zombie-testing-one-behavior-at-a-time-9s2m3zjo|Z O M B I E]].
  * primitive obsession: evitar los primitivos como enteros, strings...
  * patrón stupid: lo contrario al patrón SOLID.
  * pirámide de testing
  * mocks / dobles de prueba
  * baby steps
  * test de categorización: para trabajar con código //legacy//.
  * semantic versioning: MAJOR.MINOR.PATCH https://semver.org
  * Lenguaje ubicuo
  * smoke test
  * fixture
  * Código legacy: mal código, un código difícil de trabajar con él, principalmente porque no tiene tests, y no sigue patrones de diseño...
  * Scaffolding
  * Arquitectura por capas

==== Kata RPG Combat ====

Recomendable ir haciéndola poco a poco, iteración a iteración.

Inicial:

<code php>
use PHPUnit\Framework\TestCase;
 
class DefaultTest extends Testcase {
 
    /** @test */
    public function Given_a_number_When_translate_Then_returns_same_number() {
 
       // Arrange
       $sut = new Character();
 
       // Act
       $sut->receiveDamage(Character::MAX_LIFE+1);
 
       // Assert
       self::assertSame(0, $sut->getLife());
       self::assertFalse($sut->isAlive());
    }
}
</code>

<WRAP center round info 60%>
Lo único que se prueba en los tests son los comportamientos. La instanciación no es comportamiento.
</WRAP>

Hay dos escuelas de TDD:

  * San Francisco
  * Londres

Una es insideout (empieza desde las piezas más pequeñas hacia arriba en el comportamiento)

Otra es outside in (test que prueba la capa más superior y luego se va a lo pequeño)

Dependerá de lo que necesitemos. Desarrollos rápidos, mejor inside out.

==== Laravel 8 ====

Instalación de composer con Composer una determinada versión de Laravel:

<code>
composer create-project laravel/laravel:^8.0 nombre_proyecto
</code>

  * https://laravelversions.com

Laravel usa el patrón **MVC** (model vista controlador). Este patrón intenta separar 3 responsabilidades:

  * **Modelo**: se confunde muchas veces con el modelo de datos. En realidad es una representación de algo. Ejemplo: mundo real montaña, y en el modelo sería un mapa. 
  * **Vista**: los modelos pueblan las vistas. Conexión con el exterior. La vista tiene que ser lo más tonta posible, sin lógica (a poder ser).
  * **Controlador**: está en medio de modelo y vista. Debería ser más tonto que la vista. Alguien / algo pide algo, llega al controlador, y este ve qué modelo se necesita y qué vista se necesita. Pero no debería tomar ninguna decisión.

La mayoría de framworks trabaja con MVC.

DDD habla de necesidades y comportamientos. Dominio es la razón por la que hacemos cierto sofware. DDD se suele usar para proyectos grandes (ágil, escalable, etc)

"Fracasa rápido, fracasa barato"


Mirando la estructura de Laravel..  

  * Modelo: ''app/Models''
  * Vista: ''app/resources/views''
  * Controlador: ''app/Http''

''Middleware'': son intermediarios que usan el patrón de cadena de comandos. Desde que se hace la request hasta obtener la respuesta, pasa por todos los middlewares que haya en esa carpeta.

''app/Providers'': la "D" de SOLID indica que si tenemos que acoplarnos con algo, siempre es mejor acoplarse con un abstracto (clase abstracta o interfaz) que con un concreto. Para eso existen los contenedores de dependencias.

''bootstrap'': las clases de inicio que necesita Laravel para arrancar la aplicación.

''config/'': configuración de base de datos, correo...

  * ''database/migrations/'': se define la estructura de las tablas. La razón de hacer estas migración es la "D" de SOLID. Es abstracto para poder usar otros motores de bases de datos sin cambiar nada en las migraciones.
  * ''database/seeders/'': puebla las tablas con datos
  * ''database/factories'': indica con qué datos se rellenarán las tablas

Cada vez que se ejecuta un test, se ejecutan todas las migraciones en memoria (sqlite), para ello hay que modificar el fichero ''phpunit.xml'' (fichero de configuración de PHP Unit) y descomentar las líneas . Testing en Laravel solo se puede hacer si hay migraciones.

https://github.com/kitloong/laravel-migrations-generator

''.env'': configuración del entorno, para poder separar entornos y no compartir información privada.

13 de agosto cumpleaños de David Cruz info@davidcruz.net

Un **trait** permite que en PHP podamos tener herencia múltiple (composición). trait es como un "include". Podríamos heredar de varias clases. El problema de los "traits" en PHP es que no se pueden controlar colisiones.

''public'': el servidor web apuntará a esta carpeta. Es donde empieza todo. Aquí no tenemos que tocar nada (no se mete ni CSS ni JS...)

''resources/css'': para las hojas de estilo
''resources/js'': para todo lo de JavaScript. Laravel se lleva muy bien con [[https://vuejs.org/|Vue]].
''resources/lang'': idiomas
''resources/views'': las vistas en Laravel usan el sistema de plantillas llamado [[https://laravel.com/docs/10.x/blade|Blade]]

Mirar Tailwind CSS, le gusta al profe.

A diferencia de Symphony, Laravel está preparado para casi cualquier patrón y contempla muchos casos de uso. La desventaja es que esto hace que sea más grande y pesado que Symphony

''routes/api.php'': establece rutas para API
''routes/web.php'': son las rutas de toda la vida. A dónde tiene que ir cada petición que se hace al servidor web

''storage/app'': almacenamiento
''storage/logs'': registro de Laravel

''tests/Feature'': todo lo que no es unitario. Serían tests "subcutáneos". Están justo por debajo del frontend. Al final todo lo que no sea test unitario irá en esa carpeta. **Usa un framework de test propio de Laravel**. Estos tests **levantan toda la aplicación entera** (usa su propio servidor).
''tests/Unit'': tests unitarios. Usa [[https://phpunit.de/|PHPUnit]].

Patrón "facade" (patrón de fachada). "Estrangulan" el acceso a un software que no es el nuestro. Nos protege de tener que implementar software de terceros en nuestro dominio. En Laravel se utiliza esta fachada para trabajar con plugins de terceros.

''vendor'': todo lo de terceros. Para cada uno, Laravel tiene su "fachada".

''artisan'' aplicación en línea de comandos incluida en Laravel. Permite cosas como levantar un servidor de desarrollo:

<code>
php artisan serve
</code>

Sirve la web en la que estemos trabajando

En Laravel hay un proceso que se ejecuta cada minuto para poder hacer tareas programadas (''app/Http/Kernel.php'')

No testeamos código que no sea nuestro ya que en Laravel ya lo han hecho. Probaremos lo que hayamos desarrollado nosotros con Laravel.

La cobertura de tests también se puede hacer con PHPUnit.