Definitelytyped: Promesa<string>.toEqual no acepta el parámetro de cadena. Requiere también Promesa.</string>

Creado en 16 mar. 2017  ·  13Comentarios  ·  Fuente: DefinitelyTyped/DefinitelyTyped

  • [x] Intenté usar el paquete @types/2.5.46 y tuve problemas.
  • [] Intenté usar la última versión estable de tsc. https://www.npmjs.com/package/typescript
  • [] Tengo una pregunta que no es apropiada para StackOverflow . (Haga las preguntas pertinentes allí).
  • [] [Mencione] (https://github.com/blog/821-mention-somebody-they-re-notified) a los autores (consulte Definitions by: en index.d.ts ) para que puedan responder .

En 2.5.45 pude hacer algo como eso:
expect(element(by.id('id')).getAttribute('attr')).toEqual('myValue');
Ahora me da un error
TS2345:Argument of type '"myValue"' is not assignable to parameter of type 'Expected<Promise<string>>'.

Deja de quejarse si agrego .toString después de getAttribute, pero no estoy seguro de que funcione.

Comentario más útil

Hasta que esto se solucione, hay varias soluciones:

  1. Corrija la versión de los mecanografiados a 2.5.45
    Esto simplemente usará la última versión de trabajo.
    Arreglar la versión de mecanografiado parece convertirse en una práctica recomendada de todos modos, ya que los mecanografiados no pueden seguir a SemVer y los cambios en la versión menor pueden romper fácilmente su compilación.
    Vea estos problemas:
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14579
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14569
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14338
    https://github.com/DefinitelyTyped/DefinitelyTyped/pull/13994#issuecomment -275949045

  2. Utilice any como parámetro genérico para expect
    Los nuevos mecanografiados aún le permiten tener el comportamiento anterior, solo necesita especificar explícitamente que desea usar any como tipo como este

expect<any>(element(by.id('id')).getAttribute('attr')).toEqual('myValue');
  1. Escriba mecanografía para las funciones asíncronas expect y agréguelas a su proyecto
    Esta sería la mejor solución, pero debería ser realizada por transportador
    Probablemente se vería algo así como
    // UNTESTED CODE!
    interface AsyncMatchers<T> extends Matchers<Promise<T>> {
        toBe(expected: Expected<T>, expectationFailOutput?: any): boolean;
        toEqual(expected: Expected<T>, expectationFailOutput?: any): boolean;
        toContain(expected: T, expectationFailOutput?: any): boolean;
        not: AsyncMatchers<T>;
    }

Agregue este código en un protractor.d.ts en su proyecto en algún lugar en el que el compilador de TypeScript pueda verlo y debería resolver sus problemas, dada la promesa en expect realidad se resuelve en el tipo proporcionado en toEqual

Todos 13 comentarios

Sí, este es un gran problema para cualquiera que use transportador en TypeScript.

Parece que Jasmine (o quizás la versión de Jasmine de Transportador si lo modifica, ¿no estoy seguro?) Admite esperar una promesa y luego probar el valor resuelto de la promesa, sin que el autor de la prueba tenga que resolver la promesa por sí mismo.

Parece que @ lukas-zech-software convirtió las coincidencias en genéricas, lo cual es realmente genial, pero rompe las promesas y las coincide con sus valores resueltos.

Como ya se mencionó en los comentarios del PR, esto no es nada sobre lo que los mecanografiados de jazmín pueden hacer.

Transportador amplía la funcionalidad, por lo que tiene que proporcionar los tipos para esto.
Si hubiera algún tipo de transportador en DefinitelyTyped, esto habría ocurrido durante las pruebas, pero no las hay, por lo que no puedo solucionarlo aquí.
En realidad, Protractor no proporciona ningún tipo de mecanografía para esto, por lo que simplemente confían en expect aceptando any como parámetro

Difícilmente puedo agregar mecanografía para un expect asíncrono que no funcionará en jasmine.
Abra un problema con el transportador y pídales que extiendan las letras de jazmín correctamente.

Hasta que esto se solucione, hay varias soluciones:

  1. Corrija la versión de los mecanografiados a 2.5.45
    Esto simplemente usará la última versión de trabajo.
    Arreglar la versión de mecanografiado parece convertirse en una práctica recomendada de todos modos, ya que los mecanografiados no pueden seguir a SemVer y los cambios en la versión menor pueden romper fácilmente su compilación.
    Vea estos problemas:
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14579
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14569
    https://github.com/DefinitelyTyped/DefinitelyTyped/issues/14338
    https://github.com/DefinitelyTyped/DefinitelyTyped/pull/13994#issuecomment -275949045

  2. Utilice any como parámetro genérico para expect
    Los nuevos mecanografiados aún le permiten tener el comportamiento anterior, solo necesita especificar explícitamente que desea usar any como tipo como este

expect<any>(element(by.id('id')).getAttribute('attr')).toEqual('myValue');
  1. Escriba mecanografía para las funciones asíncronas expect y agréguelas a su proyecto
    Esta sería la mejor solución, pero debería ser realizada por transportador
    Probablemente se vería algo así como
    // UNTESTED CODE!
    interface AsyncMatchers<T> extends Matchers<Promise<T>> {
        toBe(expected: Expected<T>, expectationFailOutput?: any): boolean;
        toEqual(expected: Expected<T>, expectationFailOutput?: any): boolean;
        toContain(expected: T, expectationFailOutput?: any): boolean;
        not: AsyncMatchers<T>;
    }

Agregue este código en un protractor.d.ts en su proyecto en algún lugar en el que el compilador de TypeScript pueda verlo y debería resolver sus problemas, dada la promesa en expect realidad se resuelve en el tipo proporcionado en toEqual

Genial, gracias por aclarar esto @ lukas-zech-software. Aprecia las diferentes soluciones. Terminé bloqueando los mecanografiados a una versión anterior por ahora.

Sugiera que esto se puede cerrar.

Usar async / await para "desreferenciar" la promesa funciona.

Por ejemplo, en lugar de

it('should have header', () => {
    let subject = element(by.css('h1')).isPresent();
    let result  = true;
    expect(subject).toEqual(result);
  });

tenerlo como

it('should have header', async () => {
    let subject = await element(by.css('h1')).isPresent();
    let result  = true;
    expect(subject).toEqual(result);
  });

suponer(
para
suponer(

ha funcionado para mi

La instalación de @types/jasminewd funciona para mí, desde el enlace

beforeEach (() => {
página = nuevo xxx ();
browser.waitForAngularEnabled (falso);
});

esto resuelve el problema

Para mí, el ajuste de tsconfig.e2e.json según este comentario funcionó. Mi problema apareció al actualizar de Angular 4 a 5 en un proyecto administrado por CLI.
https://github.com/angular/protractor/issues/4176#issuecomment -310610380

Si puede vivir con la imprecisión, una solución alternativa diferente parece ser descartar toEqual con la cadena y pedir en su lugar toContain.

la instalación de @types/jasminewd2 resolvió el problema por mí

Para mí, el ajuste de tsconfig.e2e.json según este comentario funcionó. Mi problema apareció al actualizar de Angular 4 a 5 en un proyecto administrado por CLI.
angular / transportador # 4176 (comentario)

Instalar @types/jasminewd2 y hacer esto es la respuesta correcta.

Aviso, la instalación de @types/jasminewd2 __ NO ES__ una respuesta correcta:

  • jasminewd2 no es necesariamente compatible con los tipos de jazmín para v3, ya que está dirigido a jasmine v2
  • la razón por la que funciona es solo una coincidencia, ya que any -d todas las entradas.

La respuesta correcta es:

  • esperar el resultado como se describe aquí
  • extender mecanografía de transportador o crear un nuevo paquete de mecanografía que extenderá correctamente el jazmín
  • use expectAsync disponible en la última versión de jazmín.
¿Fue útil esta página
0 / 5 - 0 calificaciones