Pruebas de TDD para Service Object de Notificaciones por Correo

Contenido del curso

Introducción

Pruebas

Interacción dinámica

Notificaciones

Ciclos de vida

Cierre

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0012:18

Pruebas de TDD para Service Object de Notificaciones por Correo

Curso Intermedio de Ruby on Rails

Clase 24 de 34

Clase 24 / 34

Recursos

¿Cómo diseñar un service object aplicando TDD?

Para abordar las notificaciones por correo utilizando un service object, emplearemos la metodología TDD (Test-Driven Development), que nos obliga a pensar en la prueba antes de la implementación. A través de TDD, aseguramos un desarrollo más robusto y confiable.

¿Cómo borrar métodos ejemplo?

Comienza revisando tu modelo de task y elimina cualquier método o código de ejemplo que hayas utilizado previamente. Por ejemplo, quita el sleep 5 insertado anteriormente en la línea cincuenta y siete del método same_email, ya que fue solo un recurso didáctico. Esto optimiza el flujo de trabajo al evitar bloqueos innecesarios.

¿Cómo estructurar correctamente los directorios?

Organiza correctamente tus archivos y carpetas para un mejor manejo del código:

En el directorio raíz, crea una carpeta llamada services.
Dentro de esta carpeta, crea una subcarpeta tasks.
Mueve cualquier archivo relacionado al envío de correos a esta nueva estructura, asegurando claridad en el contexto de aplicación.

¿Qué convención utilizar para el nombre del servicio?

El nombre del servicio debe comenzar con un verbo para reflejar claramente la acción que ejecuta. En este caso, nombraríamos nuestro servicio como SendEmail o EnviarEmail. Es fundamental utilizar "CamelCase" al nombrar clases en Ruby para mantener la consistencia en el estilo de codificación.

¿Cómo definir una prueba utilizando RSpec?

Realizar pruebas efectivas con RSpec garantiza que nuestro código cumpla con las expectativas esperadas:

Configura una prueba base en un archivo con un nombre significativo, por ejemplo, task_send_email_spec.rb.
Define el descriptor (describe) empleando el respectivo name space para indicar claramente el contexto de la prueba:
```
describe Tasks::SendEmail do
```
Crea un subject para simplificar la instanciación del servicio en las pruebas:
```
let(:service) { described_class.new }
```
Establece contextos para diversas situaciones, como una tarea válida o una nula, documentando suficientemente el propósito de cada uno:
```
context 'with a valid task' do
  # Definir pruebas para tareas válidas aquí
end
```

¿Cómo crear expectativas en las pruebas?

Especifica lo que esperas que el servicio haga mediante expectativas (expectations):

Para verificar el éxito de la operación:

it 'should return success' do
  result = service.call(task)
  expect(result.success).to be true
  expect(result.message).to eq('Successful')
end

Para evaluar casos de falla, como cuando no todos los requisitos se cumplen:

context 'without a task' do
  it 'should return failure' do
    result = service.call(nil)
    expect(result.success).to be false
    expect(result.message).to eq('Fail')
  end
end

¿Cómo integrar Factory Bot para generar datos de prueba?

Integrar Factory Bot en nuestras pruebas permite crear instancias de objetos más rápidamente:

Define una fábrica para la tarea:
```
let(:task) { build(:task) }
```
Asegura que tus datos de prueba sean persistentes antes de realizar una prueba específica:
```
before(:each) do
  task.save
end
```

Este enfoque optimiza la metodología de desarrollo al permitir ejecutar pruebas unitarias en diferentes escenarios de validez y verificar qué tan eficientemente responde el servicio a estos entornos.

Resumen

¿Cómo diseñar un service object aplicando TDD?

¿Cómo borrar métodos ejemplo?

¿Cómo estructurar correctamente los directorios?

Organiza correctamente tus archivos y carpetas para un mejor manejo del código:

En el directorio raíz, crea una carpeta llamada services.
Dentro de esta carpeta, crea una subcarpeta tasks.
Mueve cualquier archivo relacionado al envío de correos a esta nueva estructura, asegurando claridad en el contexto de aplicación.

¿Qué convención utilizar para el nombre del servicio?

¿Cómo definir una prueba utilizando RSpec?

Realizar pruebas efectivas con RSpec garantiza que nuestro código cumpla con las expectativas esperadas:

Configura una prueba base en un archivo con un nombre significativo, por ejemplo, task_send_email_spec.rb.
Define el descriptor (describe) empleando el respectivo name space para indicar claramente el contexto de la prueba:
```
describe Tasks::SendEmail do
```
Crea un subject para simplificar la instanciación del servicio en las pruebas:
```
let(:service) { described_class.new }
```
Establece contextos para diversas situaciones, como una tarea válida o una nula, documentando suficientemente el propósito de cada uno:
```
context 'with a valid task' do
  # Definir pruebas para tareas válidas aquí
end
```

¿Cómo crear expectativas en las pruebas?

Especifica lo que esperas que el servicio haga mediante expectativas (expectations):

Para verificar el éxito de la operación:

it 'should return success' do
  result = service.call(task)
  expect(result.success).to be true
  expect(result.message).to eq('Successful')
end

Para evaluar casos de falla, como cuando no todos los requisitos se cumplen:

context 'without a task' do
  it 'should return failure' do
    result = service.call(nil)
    expect(result.success).to be false
    expect(result.message).to eq('Fail')
  end
end

¿Cómo integrar Factory Bot para generar datos de prueba?

Integrar Factory Bot en nuestras pruebas permite crear instancias de objetos más rápidamente:

Define una fábrica para la tarea:
```
let(:task) { build(:task) }
```
Asegura que tus datos de prueba sean persistentes antes de realizar una prueba específica:
```
before(:each) do
  task.save
end
```

Introducción

Curso Intermedio de Ruby on Rails: Migración y Optimización Avanzada

Migración de Rails a MongoDB con Mongoid y Pruebas Automatizadas

Gestión de Múltiples Versiones de MongoDB en Linux

Migración de Rails a MongoDB con Mongoid: Configuración Inicial

Migración de Modelos de Active Record a Mongoid

Migración completa de aplicaciones con MongoDB y Rails

Pruebas

Pruebas Automatizadas: Introducción a TDD y BDD en Desarrollo de Software

Creación de Fábricas Automatizadas con FactoryBot y Faker en Rails

Integración de Librerías para Pruebas Automatizadas en Rails

Pruebas de Modelos en Rails con Mongoid y RSpec

Pruebas de Validación y Guardado en Modelos Rails

Validación y Pruebas de Modelos en Ruby on Rails

Pruebas de Integración en Rails: Configuración y Ejecución Básica

Creación y prueba de tareas con métodos POST en Rails

Automatización de Pruebas con Headless Browser y Capybara en Rails

Pruebas de Sistema con KPIBara y WebDriver en Rails

Automatización de Pruebas de Sistema con Selenium y JavaScript

Interacción dinámica

Uso de CoffeeScript con Rails y Webpacker: Integración y Ejemplos

Integración de Selectize con RAILs y Webpacker

Formularios Anidados en Rails: Uso de Simple Form y Cocoon

Implementación Selectize en Formularios Dinámicos con Kokoon y CafeScript

Notificaciones

Envío de Emails Automático al Crear Tareas

Introducción a Service Objects en Ruby on Rails

Pruebas de TDD para Service Object de Notificaciones por Correo

Creación de Service Objects para Envío de Correos en Ruby on Rails

Procesos en Background con Sucker Punch en Rails

Pruebas con Doubles en Rails usando Sucker Punch

Ciclos de vida

Máquinas de Estado Finito: Conceptos y Aplicaciones Prácticas

Creación de Máquinas de Estados con AASM en Ruby on Rails

Creación de Service Object para Gestión de Estados de Tareas en Rails

Acciones de Controlador y Pruebas en Ruby on Rails

Integración de AJAX en Gestión de Estados de Tareas en Ruby on Rails

Cierre

Optimización de rendimiento en aplicaciones web con Ruby on Rails

Migración y Pruebas Automatizadas en Ruby on Rails

Pruebas de TDD para Service Object de Notificaciones por Correo