Implementación de Endpoints para Listar y Mostrar Posts con TDD

Curso de Creación de APIs con Ruby on Rails

Contenido del curso

Introducción

Proyecto

Cierre

33
Creación de APIs con Rails: Buenas Prácticas y Features Avanzados
00:43 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0015:12

Implementación de Endpoints para Listar y Mostrar Posts con TDD

Curso de Creación de APIs con Ruby on Rails

Clase 11 de 33

Clase 11 / 33

Recursos

El enfoque correcto con TDD en Rails te permite construir endpoints confiables desde el primer día. Aquí verás cómo diseñar pruebas con RSpec y generar datos con FactoryBot y Faker para los GET /posts y GET /posts/:id, validando el payload, el estado 200 y el comportamiento con y sin datos. La clave: escribir primero las pruebas, provocar los fallos esperados y luego implementar.

¿Cómo aplicar TDD para los endpoints de posts en Rails?

Es vital partir desde la carpeta spec y crear un nuevo spec para posts. Se plantean dos rutas: listar con GET /posts y mostrar con GET /posts/:id. Primero se copian y adaptan estructuras previas, luego se define qué debe ocurrir en cada caso: cuando no hay datos la lista debe estar vacía y el estado debe ser 200. Con datos insertados, el payload debe igualar en tamaño a lo creado y también responder 200.

¿Qué pruebas cubren listar y mostrar posts?

Listar sin datos: lista vacía y estado 200.
Listar con datos: tamaño del payload igual a los posts creados y estado 200.
Mostrar detalle: payload no vacío, estado 200 y el ID del payload igual al del post creado.

Ejemplo de estructura en RSpec para index y show:

# spec/requests/posts_spec.rb
require 'rails_helper'

RSpec.describe 'Posts', type: :request do
  describe 'GET /posts' do
    context 'sin datos en la base de datos' do
      it 'retorna lista vacía y 200' do
        get '/posts'
        expect(response.status).to eq(200)
        expect(JSON.parse(response.body)).to be_empty
      end
    end

    context 'con datos en la base de datos' do
      let(:posts) { FactoryBot.create_list(:post, 10, published: true) }

      it 'retorna todos los posts publicados y 200' do
        posts
        get '/posts'
        payload = JSON.parse(response.body)
        expect(response.status).to eq(200)
        expect(payload.size).to eq(posts.size)
      end
    end
  end

  describe 'GET /posts/:id' do
    it 'retorna un post y 200' do
      post = FactoryBot.create(:post)
      get "/posts/#{post.id}"
      payload = JSON.parse(response.body)
      expect(response.status).to eq(200)
      expect(payload['id']).to eq(post.id)
    end
  end
end

¿Cómo estructurar RSpec con describe, context y let?

Usa describe para agrupar por ruta o acción.
Separa escenarios con context: "con datos" y "sin datos".
Declara datos con let para crear listas con FactoryBot. Esto los hace reutilizables dentro de cada prueba.

¿Cómo generar datos de prueba con FactoryBot y Faker?

Primero, genera los factories con el generador de Rails: rails g factory bot model user email:string name:string auth_token:string y luego para post con title:string content:string published:boolean user:references. Después, ajusta los valores por defecto usando Faker para que los datos sean válidos y realistas.

¿Cómo crear factories para user y post?

# spec/factories/users.rb
FactoryBot.define do
  factory :user do
    email { Faker::Internet.email }
    name  { Faker::Name.name }
    auth_token { 'my_string' }
  end
end

# spec/factories/posts.rb
FactoryBot.define do
  factory :post do
    title     { Faker::Lorem.sentence }
    content   { Faker::Lorem.paragraph }
    published {
      r = rand(0..1)
      r == 0 ? false : true
    }
    user
  end
end

Puntos clave al crear factories:

Usa Faker para emails, nombres, títulos y párrafos.
Define published como booleano real, no nulo.
Declara la asociación con user para que se cree automáticamente.

¿Cómo usar datos aleatorios y asociaciones?

Datos aleatorios ayudan a detectar fallos por validaciones reales.
La asociación user en el factory de post evita tener que crear usuarios manualmente en cada prueba.

¿Cómo validar booleanos y solucionar errores comunes?

Al ejecutar las pruebas y la consola en el entorno de pruebas con la variable de entorno de Rails, se detectó un error típico: el validador de presencia marca false como vacío en atributos booleanos. Por eso, aunque published estaba en false, se consideraba inválido.

¿Por qué presence falla con booleanos?

El validador de presence trata false como valor vacío.
Con booleanos, false puede ser un estado válido y debe aceptarse.

¿Qué cambio hacer con inclusion para published?

Reemplaza la presencia por inclusión explícita en booleanos:

# app/models/post.rb
class Post < ApplicationRecord
  validates :published, inclusion: { in: [true, false] }
end

Además, ajusta la prueba del modelo para no requerir presencia en published. Tras este cambio, las fallas se reducen a lo esperado por TDD: rutas inexistentes aún por implementar en el controlador.

¿Quieres que revisemos la implementación del controlador y las rutas para que las pruebas pasen? Deja tus preguntas y comenta qué parte te interesa profundizar.

Diego Ortiz

Hace 8 años

¿Pero ese token que el proveedor le retorna a la SPA, también se lo tiene que hacer saber a la App no es así? De otra forma... ¿el backend cómo se va a enterar que ese token que le están enviando es valido?

Simon Soriano

Profesor

Hace 8 años

Cuando se genera un token, el proveedor (Auth0) firma lo firma con una llave privada y una llave pública. La llave privada sólamente la tiene Auth0 y debe garantizar que está bien custodiada para que podamos confiar en él y la llave pública, como su nombre lo dice, es pública y cualquiera puede verla o descargarla. Esas "llaves" son literalmente un par de strings que son generados usando unos principios matemáticos que hacen que estén "conectadas". De esta manera el que firma puede enviar mensajes firmados y cualquier persona o servicio puede verificar que el mensaje fue firmado por Auth0 usando la llave pública.

Algo así como que tu dedo es la llave privada y la foto de tu huella es la llave pública. Si tu envías una carta, pones tu huella en la carta y publícas una foto de tu huella, cualquiera podría verificar que esa carta es tuya pero nadie podría falsificar tus cartas porque nadie más tiene tu dedo para poner una huella.

En el código del proyecto, en la clase JsonWebToken puedes ver que descargamos la llave pública de para verificar el token:

class JsonWebToken
  def self.verify(token)
    JWT.decode(token, nil,
               true, # Verify the signature of this token
               algorithm: 'RS256',
               iss: 'https://simon0191.auth0.com/',
               verify_iss: true,
               aud: 'MH2k1IeuaRhWBbm6kq5wV9g1n7w7Bvfa',
               verify_aud: true) do |header|
      jwks_hash[header['kid']]
    end
  end

  def self.jwks_hash
    jwks_raw = Net::HTTP.get URI("https://simon0191.auth0.com/.well-known/jwks.json")
    jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
    Hash[
      jwks_keys
      .map do |k|
        [
          k['kid'],
          OpenSSL::X509::Certificate.new(
            Base64.decode64(k['x5c'].first)
          ).public_key
        ]
      end
    ]
  end
end

De esta manera garantizamos que solamente vamos a recibir tokens de Auth0, puesto que si recibimos un token que no haya sido firmado por Auht0, la validación con la llave pública va a fallar.

Comentarios (20)20 comentarios

Pedro Luis Botero Cardona

Hace 7 años

Nico Melgarejo Sabelle

Víctor de Jesús Pacheco Padilla

Hace 6 años

Gael Geovani Manzanares Quiñones

Oscar Guadalupe Pérez Ayuso

Henry Leonardo Rodríguez Pérez

Hace 3 años

William Calderón Castillo

Eleonora Lester

Victor Manuel Franco Cañon

Angela Soler

Hace 5 años

Daniel J. Pérez

Jorge Diaz

Martín Fernando López Moguel

Miguel Prada

Johan Donado

Armando Catalán

Adrian Peralta

Plataforma Juried

Hace 4 años

Cath Salguero

Leonardo Moreno

Piero Nolte

Hace 2 años

Cristopher Reynaldo Huaroc Olivera

Jhonnatan Alexander Casas Leon

Diego Camacho

Sergio Antonio Ordoñez González

Alexander Nova Arevalo

Introducción

API de blog con Ruby on Rails y TDD

Verificar herramientas antes del proyecto Rails

Proyecto

Creación de APIs con Rails: Proyecto Blog API paso a paso

Configuración de Gemas para Pruebas en Proyectos Rails

Configuración de Gemas en Proyectos Rails: Arspec, Factory Bot y Database Cleaner

Implementación de un Health Check Endpoint en API con RSpec

Diseño de Casos de Uso y Diagramas de Entidad para Aplicaciones

Diagrama entidad relación: usuario y post

Modelado de Aplicaciones con TDD en Rails

Validaciones y Pruebas TDD en Rails: Modelos USR y Post

Implementación de Endpoints para Listar y Mostrar Posts con TDD

Implementar controlador Posts con TDD

Pruebas TDD para crear y actualizar posts

Implementación de Métodos y Manejo de Excepciones en Rails API

Active Model serializers: control total de JSON en Rails

Búsqueda y Filtrado de Posts por Título con TDD

Implementación de Búsqueda de Posts con Servicios en Rails

Problema N+1 en Rails: Detección y Solución Eficaz

Identificación y solución del problema N+1 en Rails

Flujo de Autenticación en APIs con Tokens y Proveedores

Tests con RSpec para autenticación de tokens

Autenticación con Tokens: Implementación en Rails API

Autenticación de Usuarios en Controladores Rails

Autenticación y Seguridad en CRUD de Posts en Rails

Pruebas de Creación y Actualización con Autenticación en Rails

Probando API Ruby on Rails con Postman

Caching en Aplicaciones Web: Funciones y Niveles

Aceleración de Búsquedas en Rails con Caching

Background Jobs en Rails: Conceptos y Funcionalidades

Procesamiento en Background y Envío de Correos con Rails

Envío de Correos en Rails con ActionMailer y Background Jobs

Autenticación y Autorización con JWT y Auth0 en Aplicaciones Web

Cierre

Creación de APIs con Rails: Buenas Prácticas y Features Avanzados

Implementación de Endpoints para Listar y Mostrar Posts con TDD