Introducción

1

Creación de APIs en Ruby on Rails: Pruebas y Autenticación

2

Verificación de Entorno para Desarrollo en Ruby y Rails

Proyecto

3

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

4

Configuración de Gemas para Pruebas en Proyectos Rails

5

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

6

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

7

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

8

Diagrama de Entidad Relación para Modelos de Aplicación

9

Modelado de Aplicaciones con TDD en Rails

10

Validaciones y Pruebas TDD en Rails: Modelos USR y Post

11

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

12

Implementación de Pruebas y Controladores en Rails

13

Creación y Actualización de Posts con Pruebas TDD

14

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

15

Serialización de Modelos en Rails con ActiveModelSerializer

16

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

17

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

18

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

19

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

20

Flujo de Autenticación en APIs con Tokens y Proveedores

21

Pruebas de Autenticación en API con Test Driven Development

22

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

23

Autenticación de Usuarios en Controladores Rails

24

Autenticación y Seguridad en CRUD de Posts en Rails

25

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

26

Pruebas de API con Postman: Ejecución y Verificación de Respuestas

27

Caching en Aplicaciones Web: Funciones y Niveles

28

Aceleración de Búsquedas en Rails con Caching

29

Background Jobs en Rails: Conceptos y Funcionalidades

30

Procesamiento en Background y Envío de Correos con Rails

31

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

32

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

Cierre

33

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

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

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

16/33
Recursos

¿Cómo implementar búsquedas y filtros para posts por título con TDD?

La búsqueda eficiente en una base de datos es una habilidad esencial para cualquier desarrollador. Mediante el uso de Test-Driven Development (TDD), se garantiza que la lógica de búsqueda se implemente correctamente desde el inicio. En esta guía, aprenderás a implementar búsquedas y filtros para posts por título usando TDD.

¿Qué es TDD y por qué es importante?

TDD es una metodología de desarrollo de software que enfatiza la creación de pruebas antes de escribir el código funcional. Este enfoque asegura que el código satisfaga los requisitos definidos desde el principio y se mantenga limpio y fiable. Siguiendo este método, comenzamos creando pruebas que definan el comportamiento esperado.

¿Cómo crear pruebas para la búsqueda de posts?

Primero, es importante establecer el entorno de pruebas adecuadamente. Nos centraremos en pruebas unitarias para filtrar posts por título.

  1. Implementación de pruebas: Debemos crear varios posts de prueba en la base de datos. Para ello, usaremos FactoryBot.

    # Factory Bot Factories
    FactoryBot.define do
      factory :post do
        title { "Titulo de prueba" }
        published { false }
      end
    
      factory :published_post, class: 'Post' do
        title { "Titulo de prueba" }
        published { true }
      end
    end
    
  2. Configuración de datos de prueba: Crearemos tres posts con títulos similares usando estos factories.

    FactoryBot.create(:published_post, title: "Hola mundo")
    FactoryBot.create(:published_post, title: "Hola Rails")
    FactoryBot.create(:published_post, title: "Curso Rails")
    
  3. Desarrollo de la prueba de búsqueda por título: Usamos query params para buscar palabras clave en los títulos de los posts.

    # Prueba de búsqueda
    it 'debería filtrar posts por título' do
      get '/posts', params: { query: 'Hola' }
    
      expect(response).not_to be_empty
      expect(JSON.parse(response.body).size).to eq(2)
      
      ids = JSON.parse(response.body).map { |post| post['id'] }.sort
      expect(ids).to eq([id_of_hola_mundo, id_of_hola_rails].sort)
    end
    

¿Qué es un query param y cómo se usa?

Un query param es un parámetro adicional que se pasa en una solicitud HTTP, usualmente para filtrar o modificar resultados. Se agrega a la URL después de un ?, seguido por la clave y el valor del parámetro. Es una herramienta poderosa para personalizar consultas y búsquedas.

¿Cómo verificar que las pruebas fallen inicialmente?

En TDD, el objetivo inicial es que las pruebas fallen para asegurarse de que el test está correctamente configurado. Esto asegura que luego podamos proceder a escribir el código necesario para que las pruebas pasen.

  • Ejecutar pruebas: Inicia la ejecución de las pruebas en la terminal para verificar fallos intencionados.

    rspec spec/requests/posts_spec.rb
    

Si se implementa correctamente, se espera que las pruebas indiquen que los resultados no son los esperados (e.g., recibir tres posts en lugar de dos).

¿Por qué es importante que la prueba falle primero?

Esto confirma que la prueba tiene sentido y que el código aún no está implementado. Sólo después de observar un fallo, se procede a escribir el código funcional para cumplir con la prueba. Este proceso refuerza la confianza en que cualquier hecho en el código es necesario y efectivo.

Sigue aprendiendo y practica tu habilidad con TDD, una técnica poderosa que asegura un código de alta calidad, y te prepara para dominar el desarrollo ágil y eficiente.

Aportes 3

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Podría utilizarse un operador ternario en esta condicional?

Nos ahorramos unas lineas de codigo ademas de ser mucho mas legible al implementar la prueba de la siguiente forma?


  factory :post do
    title { Faker::Lorem.sentence }
    content { Faker::Lorem.paragraph }
    published {
      r = rand(0..1)
      r == 0 ? false : true
    }
    user
  end

Original

  factory :post do
    title { Faker::Lorem.sentence }
    content { Faker::Lorem.paragraph }
    published {
      r = rand(0..1)
      if r == 0
        false
      else
        true
      end
    }
    user
  end```

Espero sirva.

Tambien para implementar caracteristicas especificas, se pueden usar traits, para especificar y ser explicito en ciertas necesidades que debe de cumplir el factory:

FactoryBot.define do
  factory :post do
    title { 'Example title'}
    content { 'Example content' }
    published { false }
    user
  end

  trait :published_post do
    published { true }
  end
end

Y asi ya solo especificar el trait o traits que debera de cumplir el factory al momento de crear el objeto:

let(:example_post) { create :post, :published_post }
Alguien entiende cual el motivo de agregar get '/posts?search=Hola' si al final no esta utilizan el query param? Porque en el caso que lo utilizaría debería darle solo 2 post y no 3. En el caso que te interese en esta prueba la utilidad de un query param puedes en agregar lo siguiente: En "application\_controller.rb": ```js # GET /posts def index if params[:search].present? @posts = Post.where("title LIKE ?", "%#{params[:search]}%") else @posts = Post.where(published: true) end render json: @posts, status: :ok end ```Ejemplo de prueba "search": ```js describe "Search" do let!(:example_post_1) { create :post, :published_post, title: 'example_post_1'} let!(:example_post_2) { create :post, :published_post, title: 'example_post_2' } let!(:post_3) { create :post, :published_post, title: 'post_3' } it "should return posts by title" do get '/posts?search=post' payload = JSON.parse(response.body) expect(payload).to_not be_empty expect(payload.size).to eq(2) expect(payload.map { |p| p["id"]}.sort).to eq([example_post_1.id, example_post_2.id].sort) expect(response).to have_http_status(200) end end ``` Si generas esta prueba teniendo en cuenta un query param "search", el valor de "payload.size" seria igual 2 y buscarías que la prueba tenga éxito. En el caso que quieres que falle cambiar : expect(payload.size).to eq(3).