Referencia de Allure Chai

allureChai

• allureChai: ChaiPlugin

El plugin de Chai exportado por allure-chai. Regístralo con Chai una vez antes de que se ejecuten tus pruebas:

import { allureChai } from "allure-chai";
import * as chai from "chai";

chai.use(allureChai);

Una vez registrado, cada aserción de Chai ejecutada durante la ejecución de prueba se registrará como un paso de Allure. El plugin instrumenta el prototipo chai.Assertion, la interfaz chai.assert y los métodos estáticos usados para definir aserciones personalizadas. Llamar a chai.use(allureChai) más de una vez no tiene efecto — el plugin se protege contra la doble instrumentación.

Formato del nombre de paso

Estilo expect y should

Los pasos provenientes de aserciones expect() y .should siguen este patrón:

expect(⟨actual⟩).to[.⟨modifier⟩...][.have|.be].⟨assertion⟩[(⟨arguments⟩)]

• ⟨actual⟩ es el valor pasado a expect(), serializado como se describe en Serialización de valores.
• Los modificadores (not, deep, nested, own, ordered, any, all) se incluyen entre to y el nombre de la aserción cuando están activos en la cadena de aserción. include también aparece como modificador cuando .include (o .contain, .contains, .includes) se encadena antes de otra aserción como .members. Cuando hay varios modificadores activos, siempre aparecen en este orden fijo: not, include, deep, nested, own, ordered, any, all.
• Algunas aserciones llevan el prefijo have o be para coincidir con su expresión natural en Chai. Consulta Prefijos de ruta de aserción a continuación.
• Las aserciones de propiedad (las que no toman argumentos) omiten los paréntesis finales.

Ejemplos:

Código	Nombre del paso
expect("a").to.equal("b")	expect("a").to.equal("b")
expect(arr).to.have.lengthOf(3)	expect([...]).to.have.lengthOf(3)
expect(x).to.be.null	expect(null).to.be.null
expect(x).to.not.be.undefined	expect("foo").to.not.be.undefined
expect(obj).to.deep.equal({a:1})	expect({...}).to.deep.equal({"a":1})
expect(obj).to.have.own.property("x")	expect({...}).to.own.have.property("x")

El nombre del paso siempre sigue el patrón estructural to[.⟨modifier⟩...][.have|.be].⟨assertion⟩, independientemente del orden en que aparezcan las cadenas de lenguaje en el código. Por ejemplo, el have en .to.have.own.property(...) es una cadena de lenguaje que se descarta, y have se vuelve a añadir estructuralmente después del modificador own, produciendo .to.own.have.property(...).

Estilo assert

Los pasos provenientes de llamadas a assert.* siguen este patrón:

assert.⟨name⟩(⟨arguments⟩)

Todos los argumentos se serializan y se unen con , .

Ejemplos:

Código	Nombre del paso
assert.equal("a", "b")	assert.equal("a", "b")
assert.isTrue(false)	assert.isTrue(false)
assert.lengthOf([1,2,3], 3)	assert.lengthOf([1,2,3], 3)

Alias de nombres de aserción

Varios alias de aserciones de Chai se normalizan a sus nombres canónicos en la salida de pasos:

Alias	Se muestra como
eq, equals	equal
eqls	eql
contain, contains, includes	include
exists	exist
matches	match
throws, Throw	throw
greaterThan, gt	above
greaterThanOrEqual, gte	least
lessThan, lt	below
lessThanOrEqual, lte	most
instanceof	instanceOf
haveOwnProperty	ownProperty
haveOwnPropertyDescriptor	ownPropertyDescriptor
respondsTo	respondTo
satisfies	satisfy

Prefijos de ruta de aserción

Allure Chai añade have o be antes del nombre de la aserción en los pasos de expect/should para coincidir con la expresión natural de Chai. Los prefijos se aplican de la siguiente manera:

• .have. se añade antes de: keys, key, lengthOf, members, property, ownProperty, ownPropertyDescriptor, string. El prefijo .have. se omite cuando include es un modificador activo. Por ejemplo, expect([1,2,3]).to.include.members([2,3]) produce expect([1,2,3]).to.include.members([2,3]), no expect([1,2,3]).to.include.have.members([2,3]).
• .be. se añade antes de: a, an, arguments, Arguments, empty, exist, extensible, false, finite, frozen, instanceOf, NaN, null, ok, sealed, true, undefined.
• No se añade ningún prefijo para el resto de aserciones.

Serialización de valores

Los valores que aparecen en los nombres de pasos (tanto ⟨actual⟩ como los argumentos de aserciones) se serializan de la siguiente manera:

• Cadenas de texto se codifican en JSON, incluidas las comillas circundantes: "hello".
• Números, booleanos, null, undefined se convierten a su representación en cadena: 42, true, null, undefined.
• BigInts se serializan como ⟨value⟩n: 9007199254740993n.
• Symbols se serializan usando Symbol.prototype.toString(): Symbol(foo).
• Funciones se serializan como [Function ⟨name⟩], o [Function] si la función no tiene nombre. Las funciones constructoras que son subclases de Error (es decir, donde value.prototype instanceof Error es verdadero) se serializan solo por nombre: TypeError. Nótese que Error en sí mismo no satisface esta comprobación y se serializa como [Function Error].
• Valores RegExp se serializan usando RegExp.prototype.toString() y luego se codifican en JSON como una cadena: "/^foo$/i".
• Instancias de Error se serializan como {"name":"⟨name⟩","message":"⟨message⟩"}, tanto si aparecen como valor de nivel superior como si están anidadas dentro de objetos o arrays.
• Arrays y objetos se serializan en JSON hasta dos niveles de anidamiento. Los valores anidados a más de dos niveles se reemplazan con [Array] o [Object]. Las referencias circulares se reemplazan con [Circular].
• Valores serializados de más de 160 caracteres se truncan y se les añade el sufijo ... <truncated>.

Qué se registra y qué no

Se registra como pasos:

• Todas las aserciones de método en chai.Assertion.prototype (p. ej., equal, include, throw, match).
• Todas las aserciones de propiedad en chai.Assertion.prototype que no son cadenas de lenguaje ni modificadores (p. ej., null, ok, empty, exist).
• Métodos encadenables usados como aserciones: a, an, include, contain, contains, includes, length.
• Todos los métodos en chai.assert (p. ej., assert.equal, assert.isTrue, assert.throws). Los métodos assert.* están implementados internamente sobre expect; esas llamadas internas a expect se suprimen para que cada llamada a assert.* registre exactamente un paso, no dos.
• Aserciones personalizadas añadidas mediante chai.Assertion.addMethod(), chai.Assertion.addProperty() y chai.Assertion.addChainableMethod(). Las aserciones que ya están en el prototipo cuando se llama a chai.use(allureChai) se instrumentan en el momento del registro; las aserciones añadidas posteriormente se instrumentan en el momento de la llamada a addMethod/addProperty/addChainableMethod.
• Aserciones internas llamadas desde un callback dentro de una aserción personalizada. Estas se registran como pasos hijo anidados del paso de la aserción exterior.
• Cuando una aserción fallida lleva actual y expected en su error (como hace el AssertionError de Chai), esos valores se capturan en los detalles de estado del paso.

No se registra:

• Propiedades de cadena de lenguaje: to, be, been, is, and, has, have, with, that, which, at, of, same, but, does, still, also. Son elementos cosméticos y no tienen efecto en el reporte.
• Propiedades de modificador accedidas como parte de una cadena: not, deep, nested, own, ordered, any, all, itself. Estas no se registran como pasos en sí mismas. Todas excepto itself aparecen en el nombre del paso de aserción que les sigue; itself es una cadena silenciosa que afecta a la semántica de .respondTo() pero nunca se refleja en los nombres de pasos.
• Miembros internos de Assertion.prototype que no son aserciones orientadas al usuario: _obj, __flags, __methods, callable, iterable, numeric, assert, constructor. Estos se omiten durante la instrumentación.
• AssertionError en chai.assert. Es un constructor, no una aserción invocable, y no se envuelve.
• Las aserciones expect() integradas de Vitest. Allure Chai detecta las cadenas de aserción pertenecientes a Vitest y las omite automáticamente para evitar duplicar los pasos que allure-vitest ya registra.
• Las aserciones invocadas a través de la instancia de Chai integrada de Cypress. Allure Chai detecta cuando globalThis.Cypress está presente y la instancia de Chai registrada coincide con la propia de Cypress, y se excluye para esa instancia. Una instancia de Chai importada por separado usada en el mismo proyecto (p. ej., para aserciones de chai-http) no se ve afectada por la comprobación de Cypress y seguirá siendo registrada.