> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-e2e.md).

# Pruebas E2E

{% hint style="info" %}
Esta sección se encuentra actualmente en un trabajo en progreso (WIP).
{% endhint %}

Esta sección describe cómo los desarrolladores probarán el código base relacionado con las pruebas e2e.

## Stack de pruebas

Todas nuestras pruebas de UI DEBEN hacerse usando [Cypress](https://www.cypress.io/) como los marcos de pruebas principales junto con [Synpress](https://github.com/Synthetixio/synpress) para compatibilidad con wallets. El código de las pruebas DEBE escribirse usando [TypeScript](https://www.typescriptlang.org/) y ejecutarse usando [ts-jest](https://github.com/kulshekhar/ts-jest) para tener soporte de verificación de tipos.

## Estructura de directorios

Las nuevas pruebas DEBEN ubicarse en un `tests/e2e` directorio, en la ruta raíz. Los archivos se nombrarán según el flujo que estén probando; es decir, si el archivo de pruebas e2e va a probar el `Publicación de colección` flow, el nombre del archivo DEBE ser `collection-publication.spec.cy.ts`.

## Con qué frecuencia se ejecutarán

Programado mediante GitHub Actions. Frecuencia por definir.

## Qué probar

* Las interacciones de usuario más relevantes en las dApps (publicaciones de ítems, compras de NFTs, etc.)

## Cómo probar

Todas nuestras pruebas DEBEN seguir el estilo semiestructurado de **Dado-Cuando-Entonces** (GWT).

El siguiente ejemplo:

1. **Dado** un usuario visita `https://example.cypress.io`
2. **Cuando** hace clic en el enlace etiquetado `tipo`
3. y escribe "<fake@email.com>" en el `[data-testid="action-email"]` input
4. **Después** la URL debería incluir `/commands/actions`
5. Y el `[data-testid="action-email"]` input tiene "<fake@email.com>" como valor

Debe escribirse así:

```jsx
describe('Dado que un usuario visita https://example.cypress.io', () => {
  beforeEach(() => {
    cy.visit('https://example.cypress.io')
  })

  describe('cuando hace clic en el enlace etiquetado type', () => {
    beforeEach(() => {
      cy.contains('type').click()
    })

    describe('y escribe un correo electrónico en el input action-email', () => {
      beforeEach(() => {
        // Obtén un input, escribe en él
        cy.get('.action-email').type('fake@email.com')
      })

      it('Entonces la URL debería incluir /commands/actions', () => {
        // Debería estar en una nueva URL que
        // incluye '/commands/actions'
        cy.url().should('include', '/commands/actions')
      })

      it('y el valor del input action-email debería contener el correo electrónico escrito', () => {
        // Verifica que el valor se haya actualizado
        cy.get('.action-email').should('have.value', 'fake@email.com')
      })
    })
  })
})
```

## Pruebas de contratos

Para probar smart contracts, consulta la documentación de Solidity Standards.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-e2e.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.