Cucumber-js: Запустить определенный сценарий в версии 3

У нас есть функции, чтобы убедиться, что это работает: https://github.com/cucumber/cucumber-js/blob/v3.0.1/features/target_specific_scenarios_by_line.feature (и я только что убедился, что он все еще работает на собственном тестовом наборе cucumber-js) . Вы можете дать более подробную информацию по этому поводу? (образец структуры проекта и полная команда, которую вы выполнили) Если вы предоставляете файл и строку, он не должен запускать все сценарии. Он должен запускать только подходящие сценарии (или ни одного, если ничего не подходит).

Привет Чарли,

Пожалуйста, найдите прикрепленный тестовый проект
test-cucumber.zip

Я использую Windows 10, использую zsh, но то же самое происходит в PS.

Выполнение https://github.com/cucumber/cucumber-js/blob/v3.0.1/features/target_specific_scenarios_by_line. Тесты проходят

Загрузил свой тестовый проект, и он работает у меня (на Mac). У нас есть appveyor CI, и мы можем запускать там огурец и тот же тест.

Это очень странно. Извините, я не думаю, что могу здесь чем-то помочь. Это особенно странно, если этот тест проходит для вас локально, но тогда он не работает должным образом.

Не могли бы вы продолжить отладку, добавив несколько операторов console.log в установленный модуль узла? Некоторые места, где можно посмотреть, как распечатать argv, переданный в cli/argv_parser и какие пути к функциям передаются в pickle_filter

Нашел проблему. Запуск в PS:

У объекта featureUriToLinesMapping пути точно такие же, как и при выполнении тестов:

featureUriToLinesMapping: { '.\features\bar.feature': [ 3 ] }

где uri фильтров рассола нормализовано до:

uri: features\bar.feature

Таким образом, не соответствует this.featureUriToLinesMapping[uri];

Также в cygwin фильтр pickle нормализует путь к формату Windows вместо UNIX:

featureUriToLinesMapping: {'features / bar.feature': [3]}
uri: features\bar.feature

@charlierudolph У меня была аналогичная проблема с запуском этой функции определенного сценария по номеру строки. Я работаю на Mac, и у меня есть такая настройка проекта:

https://github.com/gd46/dibellag-automation-framework

Вы можете попробовать запустить пример с помощью:

npm test -- --browserName chrome --specs test/features/cucumber/transform.feature:14

И я все еще вижу, что все сценарии в этой функции выполняются.

@ gd46 Беглый взгляд на ваш пример, кажется, ваша структура использует --features не --specs

После дальнейшего анализа я обнаружил, что проблема является побочным эффектом этого дефекта здесь, а в protractor-cucumber-framework она появляется, когда вы передаете ему файл спецификации, он разрешает ее по абсолютному пути. И поскольку он не запускает только один сценарий, когда перед вами стоит «./», он не работает. В тот момент, когда я пытаюсь взломать protractor-cucumber-framework, чтобы получить только этот проход:

test/features/cucumber/transform.feature:14

Был запущен только один сценарий.

Поэтому я не уверен, почему путь спецификации является абсолютным, если это необходимо, или может ли он соответствовать тому, что потребитель передает в качестве спецификаций. И я не уверен, где шаблон спецификации преобразуется в абсолютный путь.

Из того, что я могу сказать, похоже, что эта строка:

https://github.com/cucumber/cucumber-js/blob/master/src/cli/index.js#L67

Возвращает featurePaths как абсолютные пути. Итак, если я напишу свои спецификации как:

test/features/cucumber/transform.feature:14

или

./test/features/cucumber/transform.feature:14

Получается:

/Users/dibellag/dibellag-automation-framework/test/features/cucumber/transform.feature

Что не позволяет мне работать с номером строки файла спецификации запуска.

@ gd46 Построитель конфигурации расширяет пути к функциям для чтения файлов, но нерасширенные пути сохраняются для параметров фильтра. https://github.com/cucumber/cucumber-js/blob/master/src/cli/configuration_builder.js#L47

Хммм ладно. Как вы думаете, проблема в транспортире? Я вижу внутри транспортира, структура огурца index.js exports.run spec - это абсолютный путь.

@charlierudolph Я попробовал то, о чем говорил

@charlierudolph Я могу проверить свой пример, если

https://github.com/cucumber/cucumber-js/blob/master/src/pickle_filter.js#L50

на следующее:

let path = require('path')
 const lines = this.featureUriToLinesMapping[path.resolve(uri)]

Это был мой небольшой прием, чтобы увидеть, как он работает в рамках моей тестовой установки.

Мне пришлось выполнить path.normalize как для getFeatureUriToLinesMapping и для matchesAnyLine чтобы пройти как мой сценарий, так и тесты библиотеки cucumber-js. Не очень, просто быстрый тест

pickle_filter.js

import _ from 'lodash'
import path from 'path'
import { TagExpressionParser } from 'cucumber-tag-expressions'

const FEATURE_LINENUM_REGEXP = /^(.*?)((?::[\d]+)+)?$/
const tagExpressionParser = new TagExpressionParser()

export default class PickleFilter {
  constructor({ featurePaths, names, tagExpression }) {
    this.featureUriToLinesMapping = this.getFeatureUriToLinesMapping(
      featurePaths || []
    )
    this.names = names || []
    if (tagExpression) {
      this.tagExpressionNode = tagExpressionParser.parse(tagExpression || '')
    }
  }

  getFeatureUriToLinesMapping(featurePaths) {
    const mapping = {}
    featurePaths.forEach(featurePath => {
      const match = FEATURE_LINENUM_REGEXP.exec(featurePath)
      if (match) {
        const uri = path.normalize(match[1])
        const linesExpression = match[2]
        if (linesExpression) {
          if (!mapping[uri]) {
            mapping[uri] = []
          }
          linesExpression
            .slice(1)
            .split(':')
            .forEach(function(line) {
              mapping[uri].push(parseInt(line))
            })
        }
      }
    })
    return mapping
  }

  matches({ pickle, uri }) {
    return (
      this.matchesAnyLine({ pickle, uri }) &&
      this.matchesAnyName(pickle) &&
      this.matchesAllTagExpressions(pickle)
    )
  }

  matchesAnyLine({ pickle, uri }) {
    const lines = this.featureUriToLinesMapping[path.normalize(uri || '')]
    if (lines) {
      return _.size(_.intersection(lines, _.map(pickle.locations, 'line'))) > 0
    } else {
      return true
    }
  }

  matchesAnyName(pickle) {
    if (this.names.length === 0) {
      return true
    }
    return _.some(this.names, function(name) {
      return pickle.name.match(name)
    })
  }

  matchesAllTagExpressions(pickle) {
    if (!this.tagExpressionNode) {
      return true
    }
    return this.tagExpressionNode.evaluate(_.map(pickle.tags, 'name'))
  }
}

@ mmuller99 Спасибо за ваши выводы. Я пытался понять, почему это не помогло мне, пару недель назад, когда я понял, что ваши выводы похожи на мои. Я думаю, нам нужно делать больше, чем просто path.normalize или path.resolve. Я думаю, что конечное решение должно делать и то, и другое, потому что в случае, когда ввод спецификации пути является абсолютным, мы всегда пытаемся сравнить его с относительным путем. Я думаю, что эти два должны быть нормализованы, чтобы они были одинаковыми, а затем использовать path.normalize, чтобы убедиться, что его окна безопасны. Мысли?

@ gd46 Спасибо за ваш вклад. Нормализация не понадобится, если мы всегда будем использовать абсолюты, поскольку пути будут нормализованы внутренне во время вызова path.resolve . Таким образом, в обоих местах требуется только path.resolve

Понятно, спасибо @ mmuller99. @charlierudolph Что вы думаете о выполнении path.resolve как для входного пути спецификации, так и для uri sourceLocation при выполнении этих сравнений, чтобы убедиться, что они всегда точны?

Я вижу, что с моей стороны он работает правильно, если я обновлю ваш path.normalize до path.resolve. Это должно решить проблему пути Windows и проблему сравнения абсолютного пути с относительным путем. Думаю, нам, наверное, стоит добавить сюда больше тестов:

https://github.com/cucumber/cucumber-js/blob/master/src/pickle_filter_spec.js

Чтобы запечатлеть эти сценарии.

@charlierudolph есть мысли?

Я хорошо использую path.resolve в обоих местах

Отличный @ mmuller99, не хотите ли вы создать PR, раз уж вы нашли проблему? В противном случае я могу создать его, если вам нужно.

@ gd64 Я добавлю PR, есть ли какие-то конкретные тестовые сценарии, на которые нам нужно обратить внимание?

Если вы можете создать неудачный тест в pickle_filter_spec, который исправляется с помощью path.resolve, это было бы здорово

Этот поток был автоматически заблокирован, поскольку после его закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему для связанных ошибок.