kaliber5 / ember-cli-yadda Goto Github PK

Hey @albertjan,

as we (@kaliber5) are still heavily invested into this addon for our projects, I would like to ask you what your thoughts are for moving the repo to our org? (as touched in #81 (comment))

This would make it more justifiable to spent more time on the addon, for e.g.

• regular maintenance (dependency updates)
• some modernization (e.g. Github actions, dependabot etc.)
• architectural changes (e.g. new step definition format, as touched in #81)

Of course this would not change the way how existing or new contributors would be able to participate if there is interest, everybody is certainly highly welcome!

/cc @lolmaus

I get the following error with a fresh install of ember-cli-mocha and ember-cli-yadda

$ ember --version
ember-cli: 2.12.0
node: 6.9.1
os: darwin x64
$ ember init
$ ember install ember-cli-mocha
$ ember install ember-cli-yadda
$ ember g feature make-a-feature
$ ember t
not ok 1 PhantomJS 2.1 - Feature: make a feature "before each" hook for "Scenario: the one where I type ember g feature"
    ---
        message: >
            Attempted to assign to readonly property.
        stack: >
            http://localhost:7357/assets/tests.js:12:16
            invoke@http://localhost:7357/assets/test-support.js:13223:25
            asyncFn@http://localhost:7357/assets/test-support.js:13208:17
            callFnAsync@http://localhost:7357/assets/test-support.js:4496:12
            run@http://localhost:7357/assets/test-support.js:4448:18
            next@http://localhost:7357/assets/test-support.js:4812:13
            http://localhost:7357/assets/test-support.js:4834:9
            timeslice@http://localhost:7357/assets/test-support.js:77:27
        Log: |
    ...
not ok 2 PhantomJS 2.1 - Feature: make a feature "after each" hook for "Scenario: the one where I type ember g feature"
    ---
        message: >
            undefined is not an object (evaluating '_this.application')
        stack: >
            http://localhost:7357/assets/tests.js:15:65
            invoke@http://localhost:7357/assets/test-support.js:13223:25
            asyncFn@http://localhost:7357/assets/test-support.js:13208:17
            callFnAsync@http://localhost:7357/assets/test-support.js:4496:12
            run@http://localhost:7357/assets/test-support.js:4448:18
            next@http://localhost:7357/assets/test-support.js:4812:13
            http://localhost:7357/assets/test-support.js:4834:9
            timeslice@http://localhost:7357/assets/test-support.js:77:27
        Log: |
    ...

I'd be tempted to raise a PR that changed https://github.com/curit/ember-cli-yadda/blob/master/lib/test-runner/mocha/acceptance.js#L8-L11 to this.application - but perhaps the scope is needed for older versions of Ember?

https://github.com/curit/ember-cli-yadda/blob/master/lib/test-runner/mocha/separate/acceptance.js works ok and uses this.application https://github.com/curit/ember-cli-yadda/blob/master/lib/test-runner/mocha/separate/acceptance.js#L12

• Recently, I upgraded my app from 2.7 to 2.9 as Qunit is upgraded in this version, my existing yadda BDD tests are also failing. Could you please fix?

Am seeing that acceptance test failures are ignored with a fresh install (ember 2.12.0) of ember-cli-mocha and ember-cli-yadda (separateSteps: true) with [email protected] and upwards ([email protected] works ok). Eg, the following test is passing:

// make-a-feature-steps.js

import steps from './steps';
import { expect } from 'chai';

export default function() {
  return steps()
    .then('I should find a file', function(next) {
      expect(false).ok;
      next();
    });
}

ember-cli-yadda is using ember 1.13.x. It is not compatible with ember 3.x . This is due to deprecations in 2.x being removed in 3.x.

ember-cli-yadda also needs to embrace new features available in later versions of 2.x and Ember 3.x, including using the Javascript modules API and the new testing API.

I am running tests using ember-cli-yadda and yadda, and using ember-cli-code-coverage.

Yadda is setting ember's global require() to its own function. This makes the coverage reporting fail in the script inserted into tests/index.html at this line of code. Since global require() is no longer ember's function, require.entries is undefined.

requirejs and requireModule are both still set to ember's require method function.

Other than asking yadda to not clobber require(), do you have any suggestions on a good way to have ember-cli-yadda work around this?

One way may be to set require = requireModule; in the generated afterEach method.

Hello,

When I install this package using ember install ember-cli-yadda, the afterInstall function in blueprints/main-index.js fails to find the yadda package to import it.

I forked the project to find a fix, but will definitely be appreciated if you find the issue before me :D

How to reproduce:

1. I'm guessing the yadda package is in your bower_components folder, so you would probably have to delete it to reproduce.
2. run ember install ember-cli-yadda

@albertjan as were in a flow right now... ;)

This is basically just an idea, and I am curious on what your opinion is about the following proposal. The problem I have been facing often times with ember-cli-yadda ist that when tests are failing you have no idea where the problem really comes from, because of all the asynchrony and the "broken" stack traces. Not even on which step the error occured.

To make this easier for us, we have been using our fork to actually include the addon, and changed the test setup (Mocha-based) a bit:

• each step is defined as a separate test (it() in mocha)
• a scenario wraps all steps in a describe
• a feature wraps all scenario in another describe
• when a step test is failing, all following steps tests are marked as pending (to prevent them from being run, as they are now defined as kind of independent tests)

Here is an example mocha output of a failing test with that setup:

You can see the code for this here: https://github.com/simonihmig/ember-cli-yadda/tree/mocha-separate-steps

Although this may seem strange at first look, this has served us quite well to easily identify where tests are failing. And it increased the test count considerably, which made us feel more comfortable! (just kidding :))

I wonder if that setup would make sense to be merged back? As a default or maybe as an option? Could put a PR together, as it is already there for Mocha, Qunit though is still missing...

Hi all! How to use parameterized steps?
I tried following:

# acceptance/steps/steps.js
var dictionary = new yadda.Dictionary()
    .define('emberUrl', /(\/\w+)/);

export default function() {
    return yadda.localisation.English.library(dictionary);
}

# acceptance/steps/my-feature-steps.js
export default function() {
    return steps()
        .given('An unauthorized user', (next) => {
            next();
        })
        .when("The user try open secure page by url $emberUrl", (next, url) => {
            ...
        });
}

And got exception:

stack: >
            TypeError: 'undefined' is not an object (evaluating 'converter.bind.apply')
                at http://localhost:7357/assets/test-support.js:2749
                at collect (http://localhost:7357/assets/test-support.js:1931)

I think I'm right in saying that I cannot access Yadda annotations, or rather, cannot control which scenarios might be run, using the default test feature template the index.js generates.

I would like to have more configuration options; e.g.

• Skip scenarios with a @Skip annotation
• The annotation @EndToEnd perhaps suggests that the scenario is only run when not using Mirage

Would we be able to make the test feature output more configurable in some way?

I may well raise a PR to do this myself if this sounds sensible.

Normally, enabling the "No try/catch" option in QUnit makes errors fall through into the browser console.

With async steps (either async function or simply returning a promise from a step) this does not happen. Debugging becomes tedious: every time I have to copy line number from QUnit reporter, open the relevant file and search for the line number.

In some of our steps we do stuff that needs to be cleaned up after a scenario has run (stubbing things for example). Preferably I would not like to add a "Then I clean everything up" step to the end of all our scenarios.

Is there a way let a step run something after a scenario finished so that the step can clean up after itself?

At the moment only a single assert is allowed per function - is this configurable?

Using ember-cli 1.13.8
ember init
ember install ember-cli-yadda

The docs say that tests/helpers/yadda.js should be installed, but I do not see it there. Am I missing something or reading the docs wrong?

Hello guys I have the following test file and the following step file

Feature: View bill
  Scenario: No bills to show
    Given There is no bills to show
    When I type in "I want to view my bill"
    Then I should see a message saying I have no bills left

and then:

export default function(assert) {
  return steps(assert).given('There is no bills to show', (next) => {
    visit('/');
    andThen(() => {
      assert.equal(currentURL(), '/', 'Visits the root path');
      next();
    });
  }).when('I type in "I want to view my bill"', (next) => {
    server.db.paymentTransactions.remove();
    next();
  }).then('I should see a message saying I have no bills left', (next) => {
    assert.ok(true);
    next();
  });
}

gives me

Expected 3 assertions, but 2 were run

ember 2.7

.given('I add something to the context', function(next) {
        // Assign 'hello' to the variable outside the step chain
        something = 'hello';
        // Assign 'there' to a new variable in `this.ctx`
        this.ctx.something = 'there';
        assert.ok(true, this.step);
        next();
      })

in localhost:4200/tests i always see:

1. Okay
2. Okay
   ..........

but must see:

1. I add something to the context

Currently ember-cli-yadda adds the following to the ember project's bower.json:

  "yadda": "acuminous/yadda#"

We work behind a corporate proxy, and when the bower install attempts to go to github it gets blocked. We would like to pull yadda from the bower registry rather than github. Could this be changed to have the following put in bower.json:

  "yadda": ">=0"

or something similar to pull the latest version from bower instead?

The yadda folks kindly fixed up their bower.json, and it appears this will work from bower now (acuminous/yadda#214).

We would appreciate if you would publish the master branch to npm as a new version.

Hi!

In my app I have a traditional tests/acceptance/foo-test.js and a new tests/acceptance/foo.feature.

Turns out, Yadda compiles the feature into a temporary file and puts it into the tests folder for QUnit to run.

The problem is that it overwrites the existing tests/acceptance/foo-test.js! The change persists since it's already under version control Tests still pass, so the autogenerated file can be checked into git by accident.

A simple solution could be to prefix autogenerated files with something a user would never write by hand, e. g. __yadda__foo-test.js instead of just foo-test.js.

Hi,

Trying to test components, missing the ember-cli moduleForComponent implementation though. Is there a way to test components with ember-cli-yadda or do I have to extend the plugin to add the module?

Cheers,
Michael

Some people get to your library when they search for BDD in Ember. Those people don't/might not know of the actual Yadda library (https://github.com/acuminous/yadda). As your current documentation is really just a supplement to the original Yadda docs, please put a link to those docs on your page.

We have installed the latest versions of ember-cli-yadda and ember-cli-blanket, with ember-cli 1.13.8. When running /tests without blanket coverage the BDD tests run fine. When running /tests?coverage to enable blanket coverage, the BDD tests fail with:

Died on test #1     at Object.TestLoader.moduleLoadFailure (http://localhost:4200/assets/test-support.js:5854:11)
    at Object.TestLoader.require (http://localhost:4200/assets/test-loader.js:31:14)
    at Object.TestLoader.loadModules (http://localhost:4200/assets/test-loader.js:21:18)
    at Function.TestLoader.load (http://localhost:4200/assets/test-loader.js:40:24)
    at http://localhost:4200/assets/test-support.js:5863:16: Could not find module yadda@ 1 ms
Source:     
Error: Could not find module yadda
    at missingModule (http://localhost:4200/assets/vendor.js:125:11)
    at requireModule (http://localhost:4200/assets/vendor.js:135:17)
    at require (http://localhost:4200/assets/blanket-loader.js:128:16)
    at http://localhost:4200/assets/sf-todo.js:1201:23
    at mod.state (http://localhost:4200/assets/vendor.js:150:29)
    at tryFinally (http://localhost:4200/assets/vendor.js:30:14)
    at requireModule (http://localhost:4200/assets/vendor.js:148:5)
    at require (http://localhost:4200/assets/blanket-loader.js:128:16)
    at oldLoader (http://localhost:4200/assets/blanket-loader.js:84:13)
    at Object._blanket.extend.utils.processFile (http://localhost:4200/assets/test-support.js:12100:17)

I'm not sure of the exact problem, but perhaps this is related. yadda-0.15.4 sets the global 'require' to its own function when it is loaded. This changes it from pointing to the usual ember-cli loader.js require function. This doesn't seem to be a problem when ember-cli-blanket coverage is off, although the global 'require' stays as the yadda function instead of the loader.js function for the rest of the load process.

But, when ember-cli-blanket coverage is on, ember-cli-blanket sets the global 'require' to its own function, which internally turn calls the global 'requirejs', which is the loader.js require function.

• note it the add-on doing this, not blanket.js itself
• normally the global 'require' and 'requirejs' both point to the loader.js function, but yadda changes that

That's a little confusing to explain, but its seems ember-cli-blanket ends up calling a different require function that what was used to load yadda. If a different registry is used in each function, then 'yadda' may not be found.

Has anyone else seen this? Ideas on how to fix?

Trying to use ember-cli-yadda in Ember CLI 3.1.0-beta.1, and it fails with error from title.

Note that modern test structure does not have start-app and destroy-app: http://www.ember-cli-diff.org/?#/v2.18.2/v3.1.0-beta.1

Related RFCs:

• https://github.com/emberjs/rfcs/blob/master/text/0232-simplify-qunit-testing-api.md
• https://github.com/emberjs/rfcs/blob/master/text/0268-acceptance-testing-refactor.md

I got error SyntaxError: Invalid character: '`' (line 1670)
while testing in PhantomJS 2.0

It is because of single quote here:

This happens with the latest ember-cli-yadda version 0.2.3

Consider this step:

.then("should not crash", async function () {
  throw new Error("Oops, it crashed");
})

For me, it results in QUnit hanging and timing out. The error is visible in console as "uncaught error in promise", but not in QUnit output.

Likely an issue upstream. I tried to follow Yadda codebase from here and got lost in callbacks.

It seems when using the addon the yadda/lib/* modules land in vendor.js, i.e. get shipped to the user! 😩

I believe the underlying issue is more related to ember-auto-import not correctly putting it into the right bundle. Will file an issue there also, but keep this up here for visibility.

Coming back to this after a few months the default behaviour for the mocha test runner to do all the steps in one test seems a bit awkward. I suggest we make separateSteps: true the default behaviour.

@adamjmcgrath what do you think.

Hey,
please use semantic versioning, as your change in 0.2.3 update broke mine projects.
You added new file that is required. I know it's in blueprint, but with automated builds( use npm install ) won't fire blueprint.

That way adding new required file is breaking change so it should be change to 0.3.0.

Thanks

Currently there is no infrastructure to test the Mocha side of things.

We should figure out how to run the whole test suite for Mocha as well. Using ember-try it would probably be possible to write scenarios that remove ember-qunit and add ember-mocha.
We still have the issue that the step files are coupled to qunit (example), so some way to add dual support for both testing frameworks in a single file, or exchanging the step files with some other mocha based ones would be needed...

Document table usage. In the video there is a demonstration of using a table in tests but there is no documentation in the README.md.

afterInstall() at this line of code needs to return the promise:

return this.addAddonToProject('ember-browserify');

to have the install wait on ember-browserify to install.

The work around is to manually run ember install ember-browserify.

Sorry I didn't catch this earlier when we were looking at the PR.

Will async/await work in ember-cli-yadda steps? If so, can you share how it can work?

I attempted to use async/await without success as shown below. The steps ran out of order.

.given('a user visits the home page', async function(next) {
      await homePage.visit();
      assert.ok(homePage.isVisible, 'at the home page');
      next();
    })

I have such feature:

Feature: main feature
  Scenario: 1 scenario
    When 1 step
    Then finish
  Scenario: 2 scenario
    When 2 step
    Then finish

How can I use steps from 2 different files (steps/first.js, steps/second.js) ?

import first_steps from './steps/first.js';
import first_steps from './steps/second.js';

export default function (assert) {
  return ...; // what I must return here?
}

    .given('a $string component', async function(componentName) {
      this.render(Ember.HTMLBars.compile(`{{${componentName}}}`));
      assert.ok(true, this.step);
    })

The DOM is empty after this step.

@albertjan shall I remove all branches except master and update-dependencies? They seem pretty old without any new functionality.

I am trying to authenticate my application using the ember-simple-auth test helpers. It needs access to an app instance. In a normal test it is available at the top of the module scope. Is it possible to access this from within a steps file?

JSHint stuck on feature files.

When I try to run tests in cli, it can't go thru feature files.
JSHint stuck on them and starts from beginning.
In browser everything is fine.

ember cli 2.11.1
ember-cli-yadda 0.2.1

All the properties that setupApplicationTest() sets up on your test's this context exist properly, except for element (the tests's root element). This is due to two unfortunate coincidences:

• this.element is set up lazily after the first visit() call here: https://github.com/emberjs/ember-test-helpers/blob/cce178256ae0e2946c76961fee29fa6d6df6f2fc/addon-test-support/%40ember/test-helpers/setup-application-context.js#L23-L27
• yadda does not preserve the context instance, but rather copies all props over to its own context at the beginning of a test run: https://github.com/acuminous/yadda/blob/bd3b74b72bcecdcf2ffa9937b6d0cbc1a36ce03d/lib/Yadda.js#L25

This means the lazily added element does not get added to the actual yadda context that the step function will see, so this.element is undefined there.

Don't know yet how to best fix this. For now you can workaround this by not using this.element but find()/findAll() (exposed by @ember/test-helpers) instead!

Hi there,

I've recently upgraded a project to the new testing format, and followed the instructions in the README, however, the scope of this inside my step file is wrong as it does not have a this.element as the docs suggest it should.

Below is a simplified version of my steps file, have put it all in steps.js for brevity.

// steps.js
import { visit, click, currentURL } from '@ember/test-helpers';
import yadda from '../../helpers/yadda';

export default function(assert) {
  return yadda.localisation.default.library()
  .given('I am on the dashboard', async function() {
    await visit('/');
  })
  .when('I click the learning link', async function() {
    await click('a.learning');
  })
  .then('I should see a list of learning activities', async function() {
    // this.element is undefined here
    assert.equal(this.element.querySelector('ul.posts li').textContent, 'My new post');
  })
}

I'm not sure if some of my setup is wrong or if this is a bug. Any help greatly appreciated.

Thanks!

We inject this webpack config to make yadda work with webpack (see here), but this only works for webpack v4 (used by eai v1). eai v2 uses webpack v5, which throws when seeing that config. We probably need to change the config conditionally based on the version of eai the app uses, so for webpack v5 it should be like this (quickly tested locally):

        resolve: {
          fallback: {
            fs: false,
            path: false,
            process: false,
          },
        }

See

• https://github.com/ef4/ember-auto-import/blob/master/docs/upgrade-guide-2.0.md
• https://gist.github.com/ef4/d2cf5672a93cf241fd47c020b9b3066a#replacing-a-node-module-with-an-empty-implementation

cc @lolmaus