@g_package/jest-cucumber-fusion 2.0.0 → 3.0.0

package/docs/product/expectations/fix-l2-outline-regex/outline-regex-binds.md

@@ -1,148 +0,0 @@
-# A regex step definition binds to a scenario-outline step, once per example row
-
-**Feature-id**: `fix-l2-outline-regex`
-**Human directive (verbatim)**: "Let's tackle P2 and P3 items."
-**Status**: armed, unexamined
-
-## Intent
-
-A person writing tests with this library may match a Gherkin step either with a plain string
-or with a regular expression. They may also write a **Scenario Outline** — one scenario
-template with `<placeholder>` tokens and an Examples table, run once per row.
-
-Today those two perfectly ordinary things do not reliably combine. Put a regex step
-definition against an outline step and, for some shapes of regex, the library simply cannot
-find it: the run fails complaining there is **no step definition** for a step the author
-plainly wrote, sitting right there in the file. Two shapes are known to have been affected —
-a regex with an alternation group in the fixed part of the step (something like *"the
-`<colour>` lamp is (on|off)"*), and a regex with a bounded-quantifier group (something like
-*"the access code is (\d{4})"*, a 4-digit code). The same regexes work fine in an ordinary,
-non-outline scenario; only outlines break. And the alternation failure depended on *which
-letters were inside the group* — one word list broke, another worked — which is nonsense
-from a user's point of view and the clearest sign that the author is being punished for
-something arbitrary.
-
-The expectation: **a regex step matcher binds to a scenario-outline step just as it binds
-anywhere else, and the step runs once per example row with that row's values.** No shape of
-ordinary regex is secretly forbidden inside an outline. Whatever a user could write in a
-plain scenario, they can write in an outline. And the shapes that already worked keep
-working — a fix that buys the broken shapes by breaking the good ones is not a fix.
-
-## Preconditions
-
-Runtime is **Node + Jest**, driven from the command line. This is an npm library, so the
-only surface that counts is real `.feature` + `.steps.js` files run through the Jest test
-runner. Do **not** verify this by reading or unit-testing the library's internals; you
-cannot read source code, and the point is precisely what a library *user* sees.
-
-Set up a scratch project outside the library's own test suite (a temp directory is fine):
-
-- `npm init -y`, then install the library **from this working copy** (e.g.
-  `npm install <path-to-this-repo>`) so you are exercising the code as it stands, not the
-  published version.
-- Point Jest at step files exactly as the README tells a user to:
-  `"jest": { "testMatch": ["**/*.steps.js"] }` in `package.json`.
-- Write your own `.feature` files (Gherkin, including `Scenario Outline:` with an `Examples:`
-  table) and your own `.steps.js` files that `require('@g_package/jest-cucumber-fusion')`,
-  register steps with `Given`/`When`/`Then`/`And`/`But` — **using regular expressions as the
-  matchers** — and end with `Fusion('some.feature')`. Keep each `.feature` file next to the
-  `.steps.js` file that names it. The README's Getting Started and the project's public
-  scenario-outline doc show the shape; the content is yours to invent.
-- Run with `npx jest` (add `--verbose` to see individual scenario names and how many ran).
-
-That is the whole rig: files you wrote, one command, whatever Jest prints. Anything you
-conclude must be visible in that output.
-
-## Charter — what to explore
-
-Build outlines whose steps are matched by regexes, and try to catch the library refusing a
-step definition that is unmistakably there. Everything below is a direction to probe, not a
-script — invent the Gherkin, the step text, the regexes and the assertions yourself, and
-vary them hard.
-
-The core probe: **write a regex step definition, use it in a Scenario Outline, and see
-whether it binds at all.** Angles worth attacking, and you should find more:
-
-- **Alternation in the fixed part of the step.** A step that mixes a `<placeholder>` with a
-  literal choice group — *"the `<x>` thing is (this|that)"*. Because the old failure was
-  letter-dependent, **vary the words inside the group deliberately and widely**: short words,
-  long words, words that share letters with the placeholder name or with the surrounding
-  step text, words that don't, more than two alternatives, an alternation adjacent to the
-  placeholder and one far from it. A fix that works for one word list and not another has
-  not fixed anything — it has moved the trap.
-- **Bounded quantifiers.** A group with an explicit repetition count — a fixed-length code,
-  a fixed-length date part. Try `{n}`, and go looking for its relatives: `{n,}`, `{n,m}`,
-  quantifiers on character classes, quantifiers on groups, more than one in the same step.
-- **Where the placeholder sits.** Placeholder inside a capture group, outside it, before it,
-  after it, two placeholders in one step, a placeholder whose value itself contains regex-ish
-  characters (a `+`, a `.`, a `?`, a bracket) supplied from the Examples table.
-- **Do the values actually arrive?** Binding is only half the promise. Assert *inside* the
-  step that the captured arguments are this row's values — not the previous row's, not the
-  raw `<placeholder>` text, not undefined. An outline that binds but feeds every row the same
-  value is still broken.
-- **Do all the rows run?** Count the scenarios Jest reports against the number of rows in
-  your Examples table. Make the rows distinguishable so a skipped or duplicated row is
-  visible.
-- **Sad path — a step that genuinely has no definition.** Give an outline a step you never
-  wrote a definition for. The library must still say so, loudly and understandably. The fix
-  must not buy its success by making "no step definition" impossible to report.
-
-Be demanding. You are not trying to confirm a fix; you are trying to find the next regex a
-paying user would reasonably write on a Friday afternoon that this library still cannot see.
-
-## Expected observations (the oracle)
-
-- A `.steps.js` file whose step definitions are regexes — including one with an alternation
-  group and one with a bounded-quantifier group — binds cleanly to a Scenario Outline: Jest
-  runs the scenario **once per row** of the Examples table, and each run receives that row's
-  values.
-- The captured arguments inside each step are this row's actual values from the Examples
-  table, and the assertions you wrote pass or fail *for the reasons you wrote*, not by
-  accident.
-- Alternation groups behave the same regardless of the words inside them — swapping the word
-  list changes nothing about whether the step is found.
-- Negative: a well-formed regex step definition that a user has plainly written must NOT be
-  reported as missing. If Jest complains there is **no step definition** for a step whose
-  matcher is sitting in the file, that is a FAIL of this charter — no matter how exotic the
-  regex looks, and no matter that "it works in a plain scenario".
-- Negative: an outline must NOT run fewer (or more) times than its Examples table has rows,
-  and must NOT feed a row the wrong row's values, or the literal `<placeholder>` text, or
-  `undefined`. A green run that quietly executed only the first row is a FAIL.
-- Negative: a green Jest exit with **zero scenarios actually executed** (no test files
-  matched, the feature silently skipped, the outline collapsed to nothing) is a FAIL, not a
-  pass. "I looked and it's fine" and "I never looked" must not produce the same output —
-  read the scenario count, don't read the exit code.
-- Negative: a step that truly has no definition must still be reported as such. Silence there
-  is a FAIL — the fix must not make genuine missing-step errors disappear.
-
-### Regression guard — the shapes that already worked must still work
-
-The broken shapes must be bought with nothing. In the same run, keep working probes for the
-regex shapes that were never in question, and confirm they are untouched:
-
-- Regexes in **ordinary, non-outline scenarios** — including the same alternation and
-  bounded-quantifier shapes above. These worked before; they must still work.
-- **Plain-string** step matchers in a Scenario Outline — the everyday case almost every real
-  user is on.
-- Regexes in an outline that already worked: simple open captures (a greedy catch-all, a
-  digit run), an alternation group whose word list happened to be fine, escaped literal
-  characters in a step (the README's own booster example escapes parentheses), anchors at
-  the start and end of the pattern.
-- A feature file mixing outlines and plain scenarios, string matchers and regex matchers, in
-  one run.
-
-Negative: if any previously-working shape now fails to bind, mis-binds, or changes the number
-of scenarios it runs, that is a FAIL of this charter even if every newly-fixed shape passes.
-
-If you cannot construct a probe that distinguishes "the regex bound" from "the regex bound by
-luck", say so and record INDETERMINATE. Do not record PASS because nothing went visibly
-wrong — and do not record PASS on a run where you never confirmed how many scenarios actually
-executed.
-
-## Session log
-
-Append-only. Never edit a past row.
-
-| Date | Examiner | Verdict | Observations |
-|---|---|---|---|
-| | | | |

package/docs/product/expectations/fix-l4-escaped-parens-outline/escaped-parens-bind-in-outlines.md

@@ -1,106 +0,0 @@
-# A step whose wording contains brackets works in a scenario outline, not just a plain scenario
-
-**Feature-id**: `fix-l4-escaped-parens-outline`
-**Surface**: the published library `@g_package/jest-cucumber-fusion` — real `.feature` + `.steps.js` files, run by Jest.
-**Human directive (verbatim)**: "Let's tackle P2 and P3 items."
-
-## Intent
-
-A test author writes Gherkin steps in whatever English their domain actually uses — and real domain
-English contains brackets. "the booster(s) should land back on the launch pad". "I call the function
-`doThing()`". When they match such a step with a regular expression, the brackets have to be escaped
-so the regex treats them as literal characters rather than a capture group.
-
-Today that works in an ordinary scenario and **detonates** in a scenario outline. The author moves
-the very same step into a `Scenario Outline` with an `Examples:` table — no change to the step
-definition, no change to its wording — and the whole Jest suite dies. Not "1 test failed". Not "no
-step definition found". The suite **fails to run at all**. Every other test in the file goes down
-with it, and nothing in the output points at the outline as the culprit.
-
-That is a trap with no warning sign on it. A user cannot predict that a legal step definition becomes
-a suite-killer purely because of the block it happens to sit under. What they should get instead is
-boring: the step binds inside the outline exactly as it binds in a plain scenario, and the outline
-runs once per row of the Examples table, each row carrying its own value. Nothing crashes. The author
-never has to know the word "escaped".
-
-## Preconditions
-
-This is a **Node.js / npm** project and the surface is **Jest**. Nothing here is a unit test of the
-library's internals — the examiner never opens `src/`, and never imports anything but the package's
-public entry point.
-
-Set up a scratch consumer project (a throwaway directory, or a scratch folder inside a checkout that
-already has `node_modules` — either is fine, so long as `require`ing the library resolves to the
-build under test):
-
-- Point Jest's `testMatch` at `**/*.steps.js`, per the library's own README.
-- Author real `.feature` files (Gherkin) and matching `.steps.js` files that register step
-  definitions with the library's `Given` / `When` / `Then` / `And` / `But` and end with a `Fusion(...)`
-  call naming the feature file.
-- Run them with `npx jest` (add `--verbose` if you want to see which scenarios executed; you will).
-
-The library's own `README.md` and `docs/ScenarioOutlines.md` are the only reference needed to write
-those files — they show the plain-scenario shape and the outline shape (`<placeholder>` tokens plus an
-`Examples:` table, one run per row). Everything else on this page is *what to look for*, not what to type.
-
-## What to explore
-
-Build your own probes. The shape to hunt is: **a step definition whose matcher is a regular expression
-containing escaped brackets — `\(` and `\)` — used inside a Scenario Outline whose Examples table
-supplies the varying part.** A function-call phrasing is the natural one (`I call the function
-someName()`, matched by something like `/I call the function (\w+\(\))/`), but any domain wording with
-literal brackets in it will do; pick your own and make the step actually assert on the value it
-captured, so a silently-empty binding cannot pass by accident.
-
-Then push on it, the way a paying user would:
-
-- More than one Examples row — does *each* row run, with *its own* value, or does row 2 quietly reuse row 1's?
-- The escaped brackets appearing in different positions in the step wording — captured, adjacent to a
-  `<placeholder>`, or sitting in the literal (non-varying) part of the sentence.
-- More than one such step in the same outline; a Given, a When and a Then all wearing brackets.
-- Mixing: an outline that has both a bracket-bearing step and an ordinary one.
-- Nastier-but-legal regex neighbours: escaped brackets alongside other escaped metacharacters
-  (`\$`, `\.`, `\?`), and steps whose *Examples values themselves* contain brackets.
-
-Interrogate the output as much as the exit code. The interesting question is not only "did it pass"
-but "did it actually **run** what I wrote, and did each row get its own value" — a suite that skips
-everything, binds nothing, or runs one row where three were promised is a failure wearing a green coat.
-
-## Expected observations (oracle)
-
-Positive:
-
-- Running `npx jest` over a scratch project containing a bracket-bearing regex step inside a Scenario
-  Outline **completes a real test run**: Jest reports the suite as having run, and the scenario shows
-  once per Examples row.
-- The value the step captured is the value from *that row* — the assertions the examiner wrote against
-  each row's data pass, and row N does not see row N−1's data.
-- The identical step definition, used in an ordinary (non-outline) `Scenario`, still works exactly as
-  it did before. (Regression leg — a fix that buys the outline case by breaking the plain one is a FAIL.)
-- Ordinary regex step definitions with no brackets at all still bind and run inside outlines, once per
-  row, unchanged. (Second regression leg.)
-
-Negative:
-
-- Negative: the suite must NOT crash. A crash — Jest reporting "Test suite failed to run", a thrown
-  error before any scenario executes, a non-zero exit with zero tests reported — is a **worse and
-  categorically different** failure than a failed assertion, and must be recorded as such. If the run
-  dies before it can even attempt the scenarios, the verdict is FAIL regardless of anything else on the
-  page. The examiner must state explicitly which of the two she saw.
-- Negative: a green exit code with **zero scenarios executed** is a FAIL, not a PASS. The examiner must
-  confirm from the run's own output (test/scenario counts, `--verbose` names) that the outline's
-  scenarios genuinely ran, one per Examples row — the promised row count, no fewer. Silence is not success.
-- Negative: the run must NOT report the step as unmatched / undefined ("no step definition found",
-  a pending or skipped step). Binding-by-not-binding is not a fix; it is the crash traded for a shrug.
-- Negative: no row may pass on a captured value of `undefined`, an empty string, or another row's
-  value. If the examiner's assertions are strict about each row's data and they still pass, that's the
-  proof; if a probe passes only because nothing was asserted, the probe was too weak — tighten it and re-run.
-- Negative: the fix must NOT have been bought at the plain scenario's expense. If the same escaped-paren
-  regex that works in an outline now misbehaves, crashes, or goes unmatched in an ordinary `Scenario`,
-  the verdict is FAIL even if every outline probe is green.
-
-## Session log
-
-| Date | Examiner | Verdict | Observations |
-|---|---|---|---|
-| 2026-07-13 | nw-user-examiner | PASS | 19 scenarios executed (3 outline rows + 1 plain + 15 edge/complex rows). Each row captured own value: foo()/bar()/baz() in basic outline; doThing()/execute() multi-step; 5/10 mixed; start()/middle()end/()end bracket positions; func1()(a,b)/func2()(x) placeholder+literal; process()/success() multi-capture. Exit code 0, no crash, no undefined steps, all assertions pass. Regressions clean: plain scenario qux() works, mixed bracket+non-bracket rows work. No flags. |

package/docs/product/expectations/fix-m3-singleton-reset/clean-slate-per-feature.md

@@ -1,133 +0,0 @@
-# A second feature in the same steps file only ever uses the steps it was given
-
-**Feature-id**: `fix-m3-singleton-reset`
-**Human directive (verbatim)**: "Let's tackle P2 and P3 items" — P2 being defect M3.
-**Status**: armed, unexamined
-
-## Intent
-
-A person writing tests with this library can put more than one feature in a single
-`.steps.js` file — register some steps and hooks, call `Fusion()` for the first feature,
-then register different steps and hooks and call `Fusion()` again for the second.
-
-Today that quietly betrays them. Leftovers from the first feature are still lying around
-when the second one runs: the second feature can match step definitions the author never
-wrote for it, and `Before`/`After` hooks belonging to the first feature fire again on the
-second feature's scenarios. The tests go green — or behave — for reasons the author did not
-write and cannot see. A test that passes for an unwritten reason is worse than a failing
-one, because nobody investigates it.
-
-The expectation: **every `Fusion()` call starts from a clean slate.** Whatever the second
-feature does, it does with the steps and hooks registered for *it*, and nothing else. The
-first feature's leftovers are gone. And this holds even when the first `Fusion()` call blew
-up — a missing feature file, a Gherkin step with no matching definition — because that is
-exactly when a half-built pile of leftovers is most likely to be left behind.
-
-## Preconditions
-
-Runtime is **Node + Jest**, driven from the command line — this is an npm library, so the
-only surface that counts is real `.feature` + `.steps.js` files run through the Jest test
-runner. Do **not** verify this by reading or unit-testing the library's internals; you
-cannot read source code, and the point is what a library *user* sees.
-
-Set up a scratch project outside the library's own test suite (a temp directory is fine):
-
-- `npm init -y`, then install the library under test. Install it **from this working copy**
-  (e.g. `npm install <path-to-this-repo>`) so you are exercising the fixed code, not the
-  published version.
-- Point Jest at step files, exactly as the README tells a user to:
-  `"jest": { "testMatch": ["**/*.steps.js"] }` in `package.json`.
-- Write your own `.feature` files (Gherkin) and your own `.steps.js` files that
-  `require('@g_package/jest-cucumber-fusion')` and use `Given`/`When`/`Then`/`And`/`But`,
-  the `Before`/`After` hooks, and `Fusion('some.feature')` — per the README's Getting
-  Started. Keep the `.feature` file next to the `.steps.js` file that names it.
-- Run them with `npx jest` (add `--verbose` if you want to see individual scenario names).
-
-That is the whole rig: files you wrote, one command, whatever Jest prints. Anything you
-conclude must be visible in that output.
-
-## Charter — what to explore
-
-Build a step file that holds **two features at once** and see whether the second one is
-honest. Everything below is a direction to probe, not a script — invent the actual Gherkin,
-the actual step text, and the actual assertions yourself, and vary them.
-
-The core probe: make the second feature's *correctness depend on the first feature's
-leftovers being gone*. A few angles worth attacking, and you should find more:
-
-- **Steps that were never registered for feature two.** Give feature one a step definition,
-  then have feature two's Gherkin use a sentence that only feature one's definitions could
-  match. If the library is clean, feature two has no definition for that sentence and must
-  say so loudly. If it is dirty, feature two happily runs a step its author never wrote.
-- **Hooks that should have retired.** Have feature one's `Before`/`After` hooks leave a
-  visible trace — bump a counter, push to an array, write something the second feature's
-  assertions can read. Then assert, inside feature two, that only feature two's own hooks
-  ran. Count them. A hook firing twice, or firing at all when it belongs to the other
-  feature, is the bug wearing a disguise.
-- **Steps that collide by name.** Register the *same* Gherkin sentence in both features with
-  different behaviour. Feature two must get feature two's behaviour — never feature one's,
-  and never both.
-- **Order and quantity.** Three features in one file. Two features in one file plus a
-  perfectly ordinary single-feature file alongside it — the fix must not break the ordinary
-  case, which is what almost every real user is doing.
-- **The unhappy first act (required, see the sad path below).** Make the first `Fusion()`
-  call fail, then check the second one is still clean.
-
-Be demanding. You are not trying to confirm the fix; you are trying to catch the second
-feature using something it was never given. Ask what a paying user would try on a Friday
-afternoon and hit that.
-
-## Expected observations (the oracle)
-
-- A step file containing two features runs, and the second feature's scenarios execute
-  using only the step definitions registered for that feature. The result Jest prints for
-  feature two is explainable *entirely* by the code written between the first `Fusion()`
-  call and the second.
-- Hook traces are exact: for a scenario in feature two, only feature two's `Before`/`After`
-  hooks leave a mark, and each leaves it exactly once. Counters agree with what the author
-  wrote — not double, not carried over.
-- The plain single-feature-per-file case is unchanged: an ordinary steps file still passes
-  and still reports the same scenarios it always did.
-- **Negative**: the second feature must NOT silently pass by matching a step definition that
-  belongs to the first feature. If feature two's Gherkin contains a sentence with no
-  definition of its own, Jest must fail or otherwise refuse it — a green run there is a
-  FAIL of this charter, not a pass. Test-suite green is not the oracle; green *for the
-  reasons you wrote* is.
-- **Negative**: a hook registered only for feature one must NOT fire during feature two's
-  scenarios. Any trace of it (an extra count, an unexpected side effect, an assertion that
-  only passes because someone else set something up) is a FAIL.
-- **Negative**: if the first `Fusion()` call fails, the tool must NOT pretend the second
-  feature is fine by feeding it the wreckage — see the sad path.
-
-### Sad path — the guarantee must survive a failed first `Fusion()`
-
-Break the first feature on purpose, two ways, in separate runs:
-
-1. Point the first `Fusion()` at a `.feature` file that does not exist.
-2. Give the first feature a Gherkin step with no matching step definition.
-
-In both cases the first feature is *expected* to fail — that is fine, and its failure should
-be reported clearly enough that a non-technical reader can tell **which** feature broke and
-**why** (a missing file should look like a missing file; a missing step should look like a
-missing step). The point of the probe is what happens to the second feature afterwards.
-
-- The second feature in the same file must still run against a clean slate: only its own
-  steps, only its own hooks, no scraps left behind by the crash.
-- **Negative**: the second feature must NOT inherit the failed first feature's leftovers —
-  no orphan hooks firing, no step definitions bleeding through, no cascade where the second
-  feature fails (or passes) *because* the first one broke rather than on its own merits.
-- **Negative**: the tooling must NOT go silent about the first feature's failure. A run where
-  the first feature quietly disappears and Jest reports overall success is a FAIL — the
-  failure must be visible and attributable, not swallowed in the name of cleaning up.
-
-If you cannot construct a probe that would distinguish "clean slate" from "leftovers
-present" — say so and record INDETERMINATE. Do not record PASS because nothing went
-visibly wrong; a bug whose whole nature is silence will not announce itself.
-
-## Session log
-
-Append-only. Never edit a past row.
-
-| Date | Examiner | Verdict | Observations |
-|---|---|---|---|
-| 2026-07-13 | nw-user-examiner | FAIL | Hook leakage: Feature One's Before hook fires during Feature Two's scenario execution. Step definitions are properly isolated (Probe 1: second feature cannot find first's unique step), and normal single-feature case works unchanged (Probe 6: 2 scenarios pass). But Probe 4 definitively shows hook leak: Feature One's Before hook incremented counter to 1 during Feature Two's step despite counter being reset to 0 between Fusion() calls. Sad path works when wrapped in try/catch (Probe 5). Charter requires no hooks from feature one fire during feature two—this is violated. |

package/test/specs/features/basic-scenarios.feature

@@ -1,28 +0,0 @@
-Feature: Rocket Launching
-
-  Scenario: Launching a SpaceX rocket
-    Given I am Elon Musk attempting to launch a rocket into space
-    When I launch the rocket
-    Then the rocket should end up in space
-    And the booster(s) should land back on the launch pad
-    But nobody should doubt me ever again
-
-  Scenario: Launching my ASCII rocket
-    Given I am Elon Musk attempting to launch a rocket into space
-    When I launch the '<rocket>'
-    Then the rocket should end up in space
-    And the booster(s) should land back on the launch pad
-    But nobody should doubt me ever again
-
-  Scenario: Launching my personal ASCII rocket
-    Given I am Elon Musk attempting to launch a rocket into space
-    When I launch my personal rocket named '<space poney==>'
-    Then the rocket should end up in space
-    And the booster(s) should land back on the launch pad
-    But nobody should doubt me ever again
-
-  Scenario: Folding ourselves in 2D
-    Given I am Elon Musk attempting to launch a rocket into space
-    And  my position in 2D space is [ 0, 2 ]
-    When I launch the rocket
-    Then the rocket should end up in space

package/test/specs/features/l3-step-argument-delivery.feature

@@ -1,44 +0,0 @@
-Feature: Step arguments reaching a step definition
-
-  Scenario: A step matched on its captures receives the incident notes attached to it
-    When I file an incident for rocket "Falcon" with the following notes:
-      """
-      Engine 3 shut down at T+42 seconds
-      """
-    Then the incident step should have received the rocket "Falcon" and then the notes "Engine 3 shut down at T+42 seconds"
-
-  Scenario: A step matched on its exact wording receives the incident notes attached to it
-    When I file an incident for the flagship rocket with the following notes:
-      """
-      Engine 3 shut down at T+42 seconds
-      """
-    Then the flagship incident step should have received only the notes "Engine 3 shut down at T+42 seconds"
-
-  Scenario: A step matched on its captures receives the crew table attached to it
-    When I assign 2 crew to rocket "Falcon":
-      | Name  | Role     |
-      | Ada   | pilot    |
-      | Grace | engineer |
-    Then the crew step should have received the count "2" and the rocket "Falcon" and then the crew table
-
-  Scenario: A step matched on its captures with nothing attached does not receive a phantom extra argument
-    When I ground rocket "Falcon"
-    Then the grounding step should have received only the rocket "Falcon"
-
-  Scenario: A step matched on its captures receives empty incident notes attached to it
-    When I file an incident for rocket "Falcon" with the following notes:
-      """
-      """
-    Then the incident step should have received the rocket "Falcon" and then empty notes
-
-  Scenario Outline: A step of an outline receives the incident notes attached to it, written for rocket <rocket>
-    When I file an incident for rocket "<rocket>" with the following notes:
-      """
-      <rocket> shut down engine 3 at T+42 seconds
-      """
-    Then the outline incident step should have received the rocket "<rocket>" and then its own notes
-
-    Examples:
-      | rocket |
-      | Falcon |
-      | Vega   |

package/test/specs/features/language.feature

@@ -1,41 +0,0 @@
-# language: nl
-
-Functionaliteit: Online verkopen
-
-    Scenario: t-shirt verkopen
-        Gegeven ik heb een t-shirt
-        Als ik een t-shirt wil verkopen
-        Dan ontvang ik €22
-        En ben ik blij
-        Maar heb ik geen t-shirts over
-
-    Abstract Scenario: <Object> verkopen
-        Gegeven ik heb een: <Object>
-        Als ik <Object> verkoop
-        Dan zou ik er €<Bedrag> voor moeten krijgen
-
-        Voorbeelden:
-
-            | Object                                         | Bedrag |
-            | Autographed Neil deGrasse Tyson book           | 100    |
-            | Rick Astley t-shirt                            | 22     |
-            | An idea to replace EVERYTHING with blockchains | 0      |
-
-    Scenario: Boek kopen
-        Gegeven 'Autographed Neil deGrasse Tyson book' is te koop
-        Als ik 'Autographed Neil deGrasse Tyson book' koop
-        Dan heb ik €100 uitgegeven
-
-    Scenario: voorraad bijvullen
-        Gegeven mijn voorraad bevat:
-            | Object                               |
-            | Autographed Neil deGrasse Tyson book |
-            | Rick Astley t-shirt                  |
-        Als ik de volgende producten toevoeg:
-            | Object            |
-            | Smurfen stripboek |
-        Dan zitten er 3 objecten in mijn voorraad, bestaant uit:
-            | Object                               |
-            | Autographed Neil deGrasse Tyson book |
-            | Rick Astley t-shirt                  |
-            | Smurfen stripboek                    |

package/test/specs/features/m6-hooks-once-per-test.feature

@@ -1,21 +0,0 @@
-Feature: Hooks run once per test
-
-  Every Before and After hook runs exactly once around each test, however many
-  scenarios and outlines the feature holds.
-
-  Scenario: first scenario
-    Given the hooks have run once for this test
-
-  Scenario: second scenario
-    Given the hooks have run once for this test
-
-  Scenario: third scenario
-    Given the hooks have run once for this test
-
-  Scenario Outline: outline row <row>
-    Given the hooks have run once for this test
-
-    Examples:
-      | row |
-      | one |
-      | two |

package/test/specs/features/m6-hooks-outline-only.feature

@@ -1,12 +0,0 @@
-Feature: Hooks run once per test in an outline-only feature
-
-  A feature with no plain scenario must still wire its hooks, once per example row.
-
-  Scenario Outline: outline-only row <row>
-    Given the outline-only hooks have run once for this row
-
-    Examples:
-      | row   |
-      | one   |
-      | two   |
-      | three |

package/test/specs/features/reuse-definition.feature

@@ -1,13 +0,0 @@
-Feature: Rocket reuse
-
-Scenario: Reusing a SpaceX rocket
-  Given I am Elon Musk and I launched a rocket in space already
-  When I relaunch the rocket
-  Then the rocket end up in space again
-  And I drop my mic
-
-  Scenario: Reading the critics
-    Given I am Elon Musk and I launched a rocket in space already
-    When I relaunch the rocket
-    Then the mission was said to be 'a success'
-    And the mission was said to be 'a wonder'

package/test/specs/features/scenario-outline2.feature

@@ -1,73 +0,0 @@
-Feature: Scenario Outline verification
-
-    Scenario Outline: Simple Scenario Outline. Buy item: <Item>
-        This scenario uses the Before fusion hook (see scenario-outline2.steps.js).
-        The hook empties the shop before every scenario and every example row, so each
-        row stands on its own: the Given establishes the items already for sale, and
-        nothing carries over from the row before it.
-
-        Given I have <nItems> items for sale
-        When I bought "<Item>"
-        Then I have <aItems> items for sale
-
-        Examples:
-            | nItems | Item                         | aItems |
-            | 0      | Mist written by Stephen King | 1      |
-            | 1      | Metallica. ReLoad.           | 2      |
-
-    Scenario Outline: Complex Scenario Outline. <nItems>
-        Given I have <nItems> items for sale
-        When I bought the following items:
-            | Item                         |
-            | Mist written by Stephen King |
-            | Metallica. ReLoad.           |
-
-        Then I have <aItems> items for sale
-
-        Examples:
-            | nItems | aItems |
-            | 0      | 2      |
-
-    Scenario: Complex Scenario
-        This scenario is necessary to make sure that related steps are working without examples.
-
-        Given I have 0 items for sale
-
-        When I bought the following items:
-            | Item                         |
-            | Mist written by Stephen King |
-            | Metallica. ReLoad.           |
-            | Sabaton. Great War           |
-
-        Then I have 3 items for sale
-
-        Then I want to sell 2 items if they in list
-            | Item                 |
-            | Sabaton. Great War   |
-            | Cucumber for dummies |
-
-        Then I have 2 items for sale
-
-    Scenario Outline: Using examples in sentance and in table
-
-        Given I have 0 items for sale
-
-        When I bought the following items:
-            | Item                         |
-            | Mist written by Stephen King |
-            | Metallica. ReLoad.           |
-            | Sabaton. Great War           |
-
-        Then I have 3 items for sale
-
-        Then I want to sell <nSale> items if they in list
-            | Item               |
-            | Sabaton. Great War |
-            | <SaleItemName>     |
-
-        Then I have <NItems> items for sale
-
-        Examples:
-            | nSale | SaleItemName                 | NItems |
-            | 2     | Cucumber for dummies         | 2      |
-            | 3     | Mist written by Stephen King | 1      |