Cucumber-js: Führen Sie ein bestimmtes Szenario in v3 aus

Wir haben Funktionen, um zu überprüfen, ob dies funktioniert: https://github.com/cucumber/cucumber-js/blob/v3.0.1/features/target_specific_scenarios_by_line.feature (und ich habe gerade überprüft, dass es noch auf der eigenen Testsuite von cucumber-js funktioniert) . Können Sie nähere Angaben zu dem Thema machen? (Beispielprojektstruktur und der vollständige Befehl, den Sie ausgeführt haben) Wenn Sie eine Datei und eine Zeile angeben, sollten nicht alle Szenarien ausgeführt werden. Es sollte nur die passenden Szenarien ausführen (oder keine, wenn nichts passt).

Hallo Charlie,

Bitte finden Sie angehängtes Testprojekt
test-gurke.zip

Betreibe Windows 10 und verwende zsh, aber das gleiche passiert in PS.

Ausführen der https://github.com/cucumber/cucumber-js/blob/v3.0.1/features/target_specific_scenarios_by_line.feature-Tests bestanden

Habe Ihr Testprojekt heruntergeladen und es funktioniert bei mir (auf einem Mac). Wir haben Appveyor CI und können dort Gurken und den gleichen Test ausführen.

Das ist sehr seltsam. Tut mir leid, ich glaube nicht, dass ich hier viel helfen kann. Es ist besonders seltsam, wenn dieser Test lokal für Sie besteht, aber dann funktioniert dies nicht richtig.

Könnten Sie möglicherweise weiter debuggen, indem Sie dem installierten Knotenmodul einige console.log-Anweisungen hinzufügen? Einige Stellen, an denen Sie sich ansehen können, wie Sie das an cli/argv_parser argv ausdrucken und welche Feature-Pfade an das pickle_filter

Habe das Problem gefunden. Im PS laufen:

Das featureUriToLinesMapping-Objekt hat die Pfade genau so, wie sie beim Ausführen der Tests übergeben werden:

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

wobei der Gurkenfilter-uri normalisiert wurde auf:

uri: features\bar.feature

Also keine Übereinstimmung auf this.featureUriToLinesMapping[uri];

Auch in Cygwin normalisiert der Pickle-Filter den Pfad zum Windows-Format anstelle von UNIX:

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

@charlierudolph Ich hatte ein ähnliches Problem damit, diese Funktion dazu zu bringen, ein bestimmtes Szenario nach Zeilennummer auszuführen. Ich arbeite auf einem Mac und habe dieses Projekt-Setup:

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

Sie können versuchen, ein Beispiel auszuführen mit:

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

Und ich sehe immer noch, dass alle Szenarien in der Funktion ausgeführt werden.

@gd46 Ein kurzer Blick auf Ihr Beispiel in scheint Ihr Framework verwendet --features nicht --specs

Nach weiterer Analyse stellte ich fest, dass das Problem ein Nebeneffekt dieses Fehlers hier ist, und im Winkelmesser-Gurken-Framework scheint es, wenn Sie ihm eine Spezifikationsdatei übergeben, es durch den absoluten Pfad aufzulösen. Und da es nicht nur das eine Szenario ausführt, wenn Sie das "./" vorne haben, funktioniert es nicht. In dem Moment, in dem ich versuche, Winkelmesser-Gurken-Framework zu hacken, um genau diesen Pass zu haben:

test/features/cucumber/transform.feature:14

Es lief nur das eine Szenario.

Ich bin mir also nicht sicher, warum der Spezifikationspfad absolut ist, wenn er es sein muss oder ob er mit dem übereinstimmen kann, was der Verbraucher als Spezifikationen übergibt. Und ich bin mir nicht sicher, wo das Spezifikationsmuster in einen absoluten Pfad umgewandelt wird.

Soweit ich das bisher beurteilen kann, scheint diese Zeile:

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

Gibt featurePaths als absolute Pfade zurück. Also wenn ich meine Spezifikationen schreibe als:

test/features/cucumber/transform.feature:14

oder

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

Es kommt heraus:

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

Was nicht zulässt, dass die Zeilennummer der Ausführungsspezifikationsdatei für mich funktioniert.

@gd46 Der Configuration Builder erweitert die Feature-Pfade, um die Dateien zu lesen, aber die nicht erweiterten Pfade werden für die https://github.com/cucumber/cucumber-js/blob/master/src/cli/configuration_builder.js#L47

Hmmm okay. Glaubst du, das Problem liegt im Winkelmesser? Ich sehe im Winkelmesser-Gurken-Framework index.js exports.run spec ist der absolute Pfad.

@charlierudolph Ich habe versucht, worüber @mmuller99 in Bezug auf featureUriToLinesMapping gesprochen hat. In meinem Fall sehe ich es nicht passend, weil es den absoluten Pfad enthält und ihn mit dem relativen Pfad der Spezifikation vergleicht.

@charlierudolph Ich kann mein Beispiel testen, wenn ich diese Zeile aktualisiere:

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

Zu dem Folgendem:

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

Dies war mein kurzer Hack, um zu sehen, wie es in meinem Test-Setup funktioniert.

Ich musste path.normalize sowohl für getFeatureUriToLinesMapping als auch für matchesAnyLine , um sowohl mein Szenario als auch die cucumber-js lib-Tests zu bestehen. Nicht schön, nur ein kurzer Test

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 Vielen Dank für Ihre Ergebnisse. Ich habe versucht, herauszufinden, warum dies vor ein paar Wochen bei mir nicht funktioniert hat, als ich feststellte, dass Ihre Ergebnisse ein ähnliches Problem wie meines waren. Ich denke, wir müssen mehr tun als nur path.normalize oder path.resolve. Ich denke, die Endlösung sollte beides tun, denn in dem Fall, in dem die Spezifikationspfadeingabe absolut ist, versuchen wir immer, sie mit einem relativen Pfad zu vergleichen. Ich denke, diese beiden sollten normalisiert werden, um gleich zu sein, und dann path.normalize verwenden, um sicherzustellen, dass die Fenster sicher sind. Die Gedanken?

@gd46 Danke für deinen Beitrag. Die Normalisierung ist nicht erforderlich, wenn wir immer absolute Werte verwenden, da die Pfade während des path.resolve Aufrufs intern normalisiert werden. Dann wird also an beiden Standorten nur path.resolve benötigt

Ich verstehe, danke @mmüller99. @charlierudolph Was halten Sie davon, eine path.resolve sowohl für den Eingabespezifikationspfad als auch für die sourceLocation-URI durchzuführen, wenn Sie diese Vergleiche durchführen, um sicherzustellen, dass sie immer genau sind?

Ich sehe, dass es auf meiner Seite richtig funktioniert, wenn ich Ihre path.normalize in path.resolve aktualisiere. Dies sollte das Problem mit dem Windows-Pfad und den Vergleich des absoluten Pfads mit dem relativen Pfadproblem beheben. Ich denke, wir sollten hier wahrscheinlich mehr Tests hinzufügen:

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

Um diese Szenarien einzufangen.

@charlierudolph irgendwelche

Ich bin gut darin, path.resolve an beiden Stellen zu verwenden

Großartig @mmüller99 würdest du gerne die PR erstellen, da du das Problem gefunden hast? Ansonsten kann ich bei Bedarf eine erstellen.

@ gd64 Ich füge den PR hinzu.

Wenn Sie einen fehlgeschlagenen Test in pickle_filter_spec erstellen können, der mit path.resolve behoben wird, wäre das großartig

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.