Implementar controlador Posts con TDD

Crear un backend limpio en Rails es más simple cuando aplicas TDD, defines un controlador de posts claro y verificas tus rutas con precisión. Aquí verás cómo implementar index y show, filtrar publicados, usar resources y depurar con by book para hacer que las pruebas pasen.

¿Cómo implementar el controller de posts con index y show?

Para comenzar, se crea un archivo de controller llamado “Post Controller” y una clase con el mismo nombre en CamelCase que hereda de ApplicationController. Se definen dos métodos por convención: index para listar y show para el detalle.

¿Cómo filtrar publicados y renderizar JSON con status ok?

• Usar una consulta para traer solo los publicados.
• Renderizar la respuesta como JSON y enviar status ok.

class PostsController < ApplicationController
  def index
    posts = Post.where(published: true)
    render json: posts, status: :ok
  end

  def show
    post = Post.find(params[:id])
    render json: post, status: :ok
  end
end

¿Qué convención seguir para index y show?

• index: recibe un GET al endpoint /posts.
• show: recibe un GET al endpoint /posts/:id con el ID en la URL.
• Usar find con params[:id] para cargar el recurso.

¿Qué rutas y comandos validan los endpoints?

La definición de rutas con el método utilitario resources permite configurar el CRUD. Aquí se limita a los métodos necesarios.

¿Cómo definir resources para CRUD parcial?

• Declarar el recurso y restringir a index y show.

# config/routes.rb
Rails.application.routes.draw do
  resources :posts, only: [:index, :show]
end

¿Cómo verificar con rails routes y filtrar con grep?

• Ejecutar el comando para listar rutas.

rails routes

• Filtrar solo lo relevante con grep en sistemas tipo Unix.

rails routes | grep posts

• En Windows, usar un emulador tipo MinGW o la compatibilidad con Linux en versiones recientes.

¿Qué corrección hacer de /post a /posts en pruebas?

• Si las pruebas fallan por ruta, revisar el plural: /posts en lugar de /post.
• Actualizar las descripciones y los GET en los tests para que apunten a /posts.

¿Cómo depurar y hacer pasar las pruebas con TDD?

Al correr bundle exec rspec, se detectaron fallos por orden de ejecución y por una clave incorrecta en el render de show. La depuración con by book ayuda a inspeccionar variables y flujo.

¿Qué diferencia hay entre let y let! con lazy evaluation?

• let: evaluación perezosa (lazy). Solo se ejecuta cuando se usa la variable.
• let!: evaluación ansiosa (eager). Se ejecuta antes de cada ejemplo.
• Solución aplicada: usar let! para crear los registros antes del request y mover el get dentro del ejemplo para asegurar el orden correcto.

let!(:posts) { create_list(:post, 10, published: true) }

it 'lista posts publicados' do
  get '/posts'
  expect(JSON.parse(response.body).size).to eq(10)
end

¿Cómo usar by book para pausar y revisar variables?

• Agregar un punto de quiebre con by book en la prueba o en el controller.
• Revisar el contenido de variables como posts y el estado de la base de datos.
• Confirmar que los objetos existen antes del request.

¿Qué error típico corrige el show al renderizar el recurso?

• Se detectó que se estaba usando la clave equivocada al hacer render en show.
• Ajuste: renderizar el post correcto como JSON con status ok, haciendo coincidir la clave con el objeto esperado por la prueba.

¿Te quedaron dudas sobre resources, let! o el flujo de TDD? Comenta qué parte quieres profundizar y qué otros endpoints te gustaría cubrir.