Notas sobre la clase del 31/05/2023 del curso Curso de Laravel 8.0

Repaso de lo de ayer:

• Hacer un CRUD a través de TDD

Qué testear y qué no testear es lo difícil de averiguar. Una de las razones por las que es difícil de testear Laravel es que hay poco código nuestro. Estamos trabajando casi todo el rato en la capa de infraestructura.

Laravel “contamina” nuestros proyectos dando facilidades. Esto complica proyectos grandes o que tienen que durar mucho en el tiempo. La consecuencia es que se haga más difícil testear.

Laravel, base de datos… es capa de infraestructura. Luego hay capa de aplicación y capa de dominio.

El profesor habla de un presentación sobre diseño de software y dobles de prueba. Y se para en TDD:

• Inside Out: escuela de Chicago. Vamos de los componentes más pequeños a los grandes.
• Outside In: escuela de San Francisco. Empezamos desde el nivel más superior. Tenemos mayor control de lo que queremos implementar. También se le conoce como mocks, un tipo de doble de test (test doubles).

Los dobles de test son técnicas para romper dependencias. Tipos de dobles de test:

• Dummy: no se usa en el test, pero sirve para cubrir las dependencias. El test debería romperse si alguien lo utiliza.
• Stub: devuelve un valor al llamar a una función. Nosotros controlamos ese valor. Nos sirve para probar diferentes escenarios.
• Spy: indica si una función ha sido llamada. Nos permite controlar comportamientos internos.
• Mock: nos indica si una función ha sido llamada, cuántas veces, con qué parámetros y nos permite controlar comportamientos internos. Es un doble de test que auna todos los demás.

Hoy el profesor hará la kata Birthday Greetings. A partir de un fichero de texto que contiene tus amigos, fechas de nacimiento y e-mails. Queremos automáticamente enviar un e-mail a los amigos que estén de cumple.

Usaremos la perspectiva Outside In para el TDD. Primer test:

<?php
 
use PHPUnit\Framework\TestCase;
use App\Doamin\IDate;
 
class DefaultTest extends TestCase {
 
    /** @test */
    public function Given_a_basic_test_When_run_Then_pass() {
 
        $dateStub = $this->createStub(IDate::class);
        $dateStub->method("getDay")->willReturn(10);
        $dateStub->method("getMonth")->willReturn(1);
 
 
        // Arrange
        //$template = new BirthdayMailTemplate();
 
        $personBirthday= new Person("noBirthday", "1982/18/08", "john.doe@foobar.com");
        $personNoBirthday = new Person("birthday", "1982/01/01", "mary.ann@foobar.com");
 
        $people = [
            $personBirthday,
            $personNoBirthday
        ];
 
        /* Patrón repository  */
        $peopleRepositoryStub = $this->createStub(IPeopleRepository::Class);
 
        $peopleRepositoryStub->method("getAll")->willReturn($people);  
 
        $emailSenderSpy = $this->createMock(IEmailSender::class);
 
        // Mock Spy:
        $emailSenderSpy->expects($this->once())->method("send")->with("birthday", "mary.ann@foobar.com");
 
        // Act
        $sut = new Notifier($peopleRepositoryStub, $emailSenderSpy, $dateStub);
 
        // Assert
        $sut->sendGreetings();
 
    }
 
    // Minitest para probar el mock
    public function test_mock() {
 
        // Comprobamos un día y mes que queramos
        // para eso usamos mock, a nuestra conveniencia
        $dateStub = $this->createStub(IDate::class);
        $dateStub->method("getDay")->willReturn(10);
        $dateStub->method("getMonth")->willReturn(1);
 
        self::assertSame(1, $dateStub->getDay());
 
    }

Este test estaría en la capa de aplicación.

Las interfaces (los contratos) van en capa de dominio.

Carpeta aplicación y carpeta dominio tendrían que poder copiarse a otro framework y tendría que funcionar. La capa infraestructura es la que tendríamos que crear o adaptar en el sistema destino.

Los mocks se suelen hacer de interfaces.

PHPUnit tiene su servicio de mocks, pero también es muy popular, según el profesor, es prophecy. Otra biblioteca para mocks es mockery-

Nueva explicación sobre aplicación, dominio e infraestructura.

• Dominio: todo lo que es propio de nuestra aplicación.
• Aplicación: servicios o los casos de uso.
• Infraestructura: implementaciones concretas.

En la carpeta de infraestructura tendríamos que hacer las implementaciones propias de Symfony si lo trasladamos desde Laravel.

Edificio de oficinas:

• Dominio: personas
• Aplicación: trabajo que realizan las personas
• Infraestructura: el edificio

Si nos cambiamos de oficina, tanto las personas como el trabajo que hacían, sigue siendo el mismo. Lo que habría que adaptar es por ejemplo el listado de gente que puede entrar en la oficina.

Laravel tiene que quedar en la capa de infraestructura.

CRC cards: Class Responsibility Collaborator. En una tarjeta se pone el nombre de la clase, la responsabilidad y los colaboradores