Как получить полную трассировку стека в ошибках Test Cafe - PullRequest
0 голосов
/ 17 января 2019

Я использовал Test Cafe для написания внутренней тестовой среды, в которой действия (t.click) и утверждения (t.expect) не пишутся напрямую в спецификации, а определяются и объединяются в другие файлы.

Все круто, пока тест не завершится неудачей: в этом случае репортер Test Cafe записывает в консоли утверждение / действие не удалось и относительный фрагмент кода, но я не нашел способа понять полную трассировку стека вызовов функций измой тест сводится к ошибочным утверждениям.

Как я могу убедиться в том, что в репортере была предоставлена ​​полная трассировка стека, в которую была записана трассировка стека со всеми вызовами функции, которые сделали мой тест неудачным?

Я понял, что причина должна быть связана с тем, как async / await передается в генераторы : трассировка стека ошибки показывает только последнее выполненное ожидание, а не все предыдущие вызовы.

<section> ... </section>
<section class="section--modifier">
  <h1> ... </h1>
  <div>
    ...
    <button class="section__button">
      <div class="button__label">
        <span class="label__text">Hello!</span> <-- Target of my test
      </div>
    </button>
    ...
  </div>
</section>
<section> ... </section>
// 
// My spec file
//
import { Selector } from 'testcafe';

import {
  verifyButtonColor
} from './button';

fixture`My Fixture`
  .page`....`;

test('Test my section', async (t) => {
  const MySection = Selector('.section--modifier');
  const MyButton1 = MySection.find('.section__button');

  const MySection2 = Selector('.section--modifier2');
  const MyButton2 = MySection2.find('.section__button');

  ....
  await verifyButtonColor(t, MyButton1, 'green'); // it will fail!
  ....
  ....
  ....
  await verifyButtonColor(t, MyButton2, 'green');
});
//
// Definition of assertion verifyButtonColor (button.js)
//
import { Selector } from 'testcafe';

import {
  verifyLabelColor
} from './label';

export async function verifyButtonColor(t, node, expectedColor) {
   const MyLabel = node.find('.button__label');
   await verifyLabelColor(t, MyLabel, expectedColor);
}
// 
// Definition of assertion verifyLabelColor (label.js)
//
export async function verifyLabelColor(t, node, expectedColor) {
   const MyText= node.find('.label__text');
   const color = await MyText.getStyleProperty('color');

   await t.expect(color).eql(expectedColor, `Color should be ${expectedColor}, found ${color}`); // <-- it will FAIL!
}

Что я не получаю в репортере, так это то, что мой тест не прошел, потому что утверждение определенов «verifyLabelColor» не удалось (цвет не зеленый :(),

...
await t.expect(color).eql(expectedColor, `Color should be ${expectedColor}, found ${color}`);
...

, но в репортере у меня нет доказательств того, что произошел сбой из-за следующего стека вызовов

- await verifyButtonColor(t, MyButton1, 'green');
- await verifyLabelColor(t, MyLabel, expectedColor);
- await t.expect(color).eql(expectedColor, `Color should be ${expectedColor}, found ${color}`);

Кто-нибудь сталкивался с подобной проблемой?

Альтернативой может быть регистрация «пути» селектора, вызвавшего сбой, но, просматривая документацию Test Cafe, я не нашел возможности сделать это: зная, чтоне удалось проверить элемент с указанным ниже путем, по крайней мере, помочь понять, что пошло не так

.section--modifier .section__button .button__label .label__text

1 Ответ

0 голосов
/ 18 января 2019

Эта тема связана с предложением TestCafe: Иметь репортер со множеством стековых трасс для быстрого анализа в случае неудачи теста

Тем временем вы можете попробовать этого репортера: / testcafe-reporter-cucumber-json или, возможно, вы можете разработать свой собственный репортер

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...