Pruebas de servicios (WKC)

Los servicios de componentes bien conocidos son servidores construidos con la arquitectura de componentes bien conocidos arquitectura, donde cada parte del servicio está modularizada y encapsulada en un componente. Estos componentes, junto con la capacidad de ser fácilmente intercambiables, tienen la capacidad de ser fácilmente probados con pruebas unitarias, ya que todas sus dependencias se inyectan cuando se crean.

La prueba de estos servicios DEBERÍA hacerse usando dos tipos diferentes de prueba, unitarias y de integración. Los componentes que contienen lógica DEBEN probarse usando pruebas unitarias y los componentes que tienen principalmente interacciones con servicios externos DEBERÍAN probarse usando pruebas de integración. Es decir, un componente adaptador de base de datos que no contiene ninguna lógica y contiene principalmente consultas a la base de datos DEBE probarse de forma integrada.

Pruebas unitarias de componentes bien conocidos

Todos los componentes DEBEN tener pruebas unitarias y DEBEN escribirse siguiendo la sección definida aquí sobre cómo escribir pruebas.

Para mostrar cómo se prueban estos componentes, aquí hay un componente simple con solo un método y dos dependencias, settings y friends:

// Componente Voice

export function createVoiceComponent(dependencies: Pick<AppComponents, 'settings' | 'friends'>) {
	const { settings, friends } = dependencies

  async function canCallEachOther(caller: string, callee: string): Promise<boolean> {
	  const [callerSettings, calleeSetting] = Promise.all([settings.getPrivacySetting(caller), settings.getPrivacySetting(callee)])
	  const areFriends = await friends.areUsersFriends(caller, callee)
		return areFriends || (callerSettings !== Settings.ONLY_FRIENDS && calleeSettings !== Settings.ONLY_FRIENDS)
  }
  
  return {
	  createVoiceChat
  }
}

Para probar este componente, deben construirse mocks adecuados, es decir, mocks que tengan los tipos correctos para interoperar con el componente que se va a probar y que sean flexibles para permitirnos crear todo tipo de pruebas. Estos mocks también deberían ser inmutables entre pruebas, preservando la idea de que cada prueba se ejecuta en su propio contexto, aislado de las demás.

Estos mocks DEBERÍAN crearse usando funciones creadoras de mocks de componentes y DEBERÍAN nombrarse como createComponentNameMockedComponent. Tomando como ejemplo el componente creado arriba, aquí hay un ejemplo de cómo DEBERÍAN verse:

// Colocado en el archivo /test/mocks/settings.ts
export function createSettingsMockedComponent(overrides?: Partial<jest.Mocked<ISettingsComponent>>): jest.Mocked<ISettingsComponent> {
  return {
    getPrivacySettings: overrides?.getPrivacySettings ?? jest.fn()
  }
}

// Colocado en el archivo test/mocks/friends.ts
export function createFriendsMockedComponent(overrides?: Partial<jest.Mocked<IFriendsComponent>>): jest.Mocked<IFriendsComponent> {
	return {
	  // Tenemos la flexibilidad de definir el comportamiento de cualquiera de los métodos exportados por el componente.
	  areUsersFriends: overrides?.areUsersFriends ?? jest.fn(),
	  // Los métodos que no se usan pueden omitirse en el parámetro overrides, convirtiéndolos en un simple mock de función.
	  hasBlockedUser: overrides?.hasBlockedUser ?? jest.fn()
	}
}

Al usar estos mocks cuidadosamente colocados dentro de un beforeEach, podemos estar seguros de que los mocks se definen correctamente aislados de diferentes ejecuciones. Aquí hay un ejemplo de cómo se pueden usar estos mocks:

// Define las funciones simuladas en el contexto para que podamos cambiar su mock.
let getPrivacySettingsMock: jest.MockedFn<ISettingsComponent['getPrivacySettings']>
let areUsersFriendsMock: jest.MockedFn<IFriendsComponent['areUsersFriends']>
let voice: IVoiceComponent

beforeEach({
  getPrivacySettingsMock = jest.fn()
  areUsersFriendsMock = jest.fn()
  // Construye el mock
  const settings = createSettingsMockedComponent({ getPrivacySettings: getPrivacySettingsMock })
  // Inicializa el mock del componente solo con los métodos que se van a usar en las pruebas
  const friends = createFriendsMockedComponent({ areUsersFriends: areUsersFriendsMock })
  // Crea el componente que se va a probar usando los mocks
  voice = createVoiceComponent({ settings, friends })
})

Esta forma de definir los mocks no solo nos permite aislar correctamente los contextos de las pruebas entre ejecuciones, sino que también sienta las bases para una inicialización adecuada del contexto, ya que al tener las funciones simuladas ya definidas, es bastante fácil construir cada contexto:

// Definido después del bloque de código anterior.

describe('cuando se comprueba si dos usuarios pueden llamarse entre sí', () => {
	const calleeAddress = '0xd7D746d39D142b6bE752efd7626cE28F245a25D1'
	const callerAddress = '0x2e8b4De1230f827082202aa53d489A26163aace0'

  describe('y el callee solo acepta llamadas de amigos', () => {
    beforeEach(() => {
      // Define el mock para el contexto, haciendo que el callee 
      getPrivacySettingsMock.mockImplementation((address: string) => {
	      switch(address) {
	        case caleeAddress:
		        return Settings.ONLY_FRIENDS
		      case callerAddress:
			      return Settings.ALL
			    default:
				    throw new Error("Mock incorrecto")
	      }
      })
    })
    
    describe('y el calle y el caller son amigos', () => {
	    beforeEach(() => {
		    areUsersFriendsMock.mockResolvedValueOnce(true)
	    })
	    
	    it('debería resolverse en true', () => {
		    return expect(voice.canCallEachOther(callerAddress, calleeAddress)).resolves.toBe(true)
	    })
    })
    
    describe('y el callee y el caller no son amigos', () =>{
		  beforeEach(() => {
		    areUsersFriendsMock.mockResolvedValueOnce(false)
	    })
	    
	    it('debería resolverse en false', () => {
		    return expect(voice.canCallEachOther(callerAddress, calleeAddress)).resolves.toBe(false)
	    })
    })
  })
  
  //... otros contextos
})

Pruebas de integración

Todos los endpoints, llamadas WS RPC, jobs o tasks DEBEN probarse de forma integral y DEBEN escribirse siguiendo la sección definida aquí sobre cómo escribir pruebas. Las pruebas de integración deben colocarse bajo el test/integration directorio y deben nombrarse de acuerdo con el punto de entrada que queremos probar.

Las pruebas de integración deberían limitarse a probar condiciones de integración específicas que no pueden probarse con pruebas unitarias (consultas SQL, operaciones de Redis, etc.) y la integración entre nuestros componentes de lógica y el protocolo (HTTP, WS).

Para mostrar un ejemplo de cómo deben hacerse las pruebas de integración, probaremos una simple solicitud HTTP que recupera los amigos de un usuario.

export async function getFriendHandler(
  context: Pick<
    HandlerContextWithPath<'logs' | 'communities', '/v1/users/:user/friends'>,
    'url' | 'components' | 'params' | 'verification'
  >
): Promise<HTTPResponse<AggregatedCommunityWithMemberData>> {
  const {
    components: { friends },
    params: { id },
    verificación
  } = context

  try {
    const userAddress = verification!.auth.toLowerCase()

    return {
      status: 200,
      body: {
        data: await friends.getFriends(userAddress)
      }
    }
  } catch (error) {
  
	  if (error instanceof InvalidFriendshipRequest) {
			throw InvalidRequest(isErrorWithMessage(error) ? error.message : 'Error desconocido')
	  }

    return {
      status: 500,
      body: {
        message
      }
    }
  }
}

Y un componente friends que tiene lo siguiente:

async function getFriends(addres: string) {
	friendsDb.getFriends()
}