anacronw / js-fixtures Goto Github PK

View Code? Open in Web Editor NEW

This project forked from velesin/jasmine-jquery

60.0 60.0 15.0 650 KB

Load html fixtures for your in-browser tests/specs

License: MIT License

JavaScript 100.00%

js-fixtures's People

Contributors

Stargazers

Watchers

Forkers

meyertee jpka jfirebaugh kippisone rickeyvisinski-kanban jagoda olivoil loganom michaelxavier ricardodpsx jhartikainen krlospelaez arieldelfor lpender jkervine

js-fixtures's Issues

Make js-fixtures loadable via requirejs

Chrome fails to find elements by classname in an iframe, if the classname contains capital letters

This isn't directly related to js-fixtures, but I thought it might be nice to let other people know that the issue exists:
https://code.google.com/p/chromium/issues/detail?id=174660

I apologize in advance for making this an issue against this project; I think it will be useful for your users to see, so they don't spend hours trying to track down why they can't find elements, or blame your nice library.

cb argument duplicated

Hi,

Thanks for this library. When using the current version on bower I noticed that if you specify a callback, it gets stringified and requested of the server:

WARN [web-server]: 404: /base/dist/fixtures/function%20()%20%7B%20%20%20%20%20%20%20%20fixtureWin%20=%20fixtures.window();%20%20%20%20%20%20%20%20done();%20%20%20%20%20%20%7D?1418238967460

I am pretty sure this is due to this line:

https://github.com/badunk/js-fixtures/blob/master/fixtures.js#L34

Since you don't pop() the cb argument, it gets passed in as a callback as well as a template. I'll send a PR. Also, if you could update the version on bower after this, it would be most helpful!

Injecting <script> as the first fixture causes it to be placed in <head> instead of <body>

Discovered this one day, may be a browser behavior. Subsequent fixtures with <script> do go into .

Not sure why this happens

Using karma + sinon-chai with what I think are appropriate config parameters:

        chai.should();
        fixtures.path = 'base';
        console.log('read');
        body = fixtures.read('index2.html');
        console.log('set');
        fixtures.set(body);
        $$ = document.getElementById(fixtures.containerId).contentDocument.documentElement;
        console.log("CONTENT", $$);
        console.log('load');
        fixtures.load('index2.html');
        console.log('loaded');
        $$ = document.getElementById(fixtures.containerId).contentDocument.documentElement;
        console.log("AGAIN", $$);

is yielding:

LOG: 'read'
LOG: 'set'
LOG: 'CONTENT', <html><head><link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/ceci-broadcast.html">
    <link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/ceci-listen.html">
    <link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/ceci-element.html">
    <link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/ceci-app.html">
    <link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/ceci-card.html">
    <link rel="import" href="https://appmaker.mozillalabs.com/test_assets/ceci/test/fixtures/ceci-value-holder.html">

    <!-- The component we're testing here. -->
    <link rel="import" href="component.html">

    <script src="https://appmaker.mozillalabs.com/test_assets/vendor/polymer/polymer.min.js"></script></head></html>
LOG: 'load'
Chrome 33.0.1713 (Mac OS X 10.9.0) button "before each" hook FAILED
    TypeError: Cannot read property 'innerHTML' of null
        at addToContainer (/Users/davida/src/mozilla-appmaker/component-button/fixtures.js:91:44)
        at self.load (/Users/davida/src/mozilla-appmaker/component-button/fixtures.js:34:13)
        at Context.<anonymous> (/Users/davida/src/mozilla-appmaker/component-button/jasmine.js:17:15)
        at Hook.Runnable.run (/Users/davida/src/mozilla-appmaker/component-button/node_modules/mocha/mocha.js:4263:32)
        at next (/Users/davida/src/mozilla-appmaker/component-button/node_modules/mocha/mocha.js:4526:10)
        at /Users/davida/src/mozilla-appmaker/component-button/node_modules/mocha/mocha.js:4538:5
        at timeslice (/Users/davida/src/mozilla-appmaker/component-button/node_modules/mocha/mocha.js:5531:27)
Chrome 33.0.1713 (Mac OS X 10.9.0): Executed 1 of 1 (1 FAILED) ERROR (1.539 secs / NaN secs)

meaning that set(read('index2.html')) is working, but load('index2.html') is resulting in an exception.

Any idea?

load has a synchronous API, but is actually somewhat async

Which is to say, I'm trying to use js-fixtures for integration testing. This means I'm using the real main page of my app, which has a whole bunch of different things.

The usage pattern described in the README blows with $$ being undefined, because, I think, the jQuery script load inside the fixture hasn't finished by the time the call to load() returns. The evidence for this is that if I set a breakpoint in a JS debugger just before assigning to $$, and then step a couple of lines, (with the human delay giving the jQuery load time to complete), then the next statement executes without error.

XMLHttpRequest not found

I am running a node test that is loading some fixtures. I have version 1.5.3 of js-fixtures. Version 3.6.0 of node.

I have a problem running npm test, the code gets to loadFixtureIntoCache on line 108 and then, 2 lines later instantiates a new instance of XMLHttpRequest - var request = new XMLHttpRequest();
This line fails with:
ReferenceError: XMLHttpRequest is not defined
at loadFixtureIntoCache (node_modules/js-fixtures/fixtures.js:110:25)

I have looked and searched everything I can think of. I use PHPStorm as my IDE and it can locate XMLHttpRequest just fine if I try to link from that reference on line 110.
I do suspect a setting somewhere. Help would be appreciated.

Load fixtures.body() as DOM

For traversal etc. I think, it would be handy to have the ability to load content as DOM.

Therefore, I extended your API to realise that.

PR coming soon.

Documentation improvement on loading fixture

It seems to be fixtures.load will make the iframe to be null on the document unless you wait for it. Meaning to say it is a bit like async. With mocha, I have to do this in order to have iframe's document loaded.

beforeEach(function(done) {
  fixtures.load('index.html', function() {
    // I needed to tell mocha it has been loaded
    done();
  });
});

Maybe the document can improve or is my understanding of fixtures loading wrong :(

Using Karma, mocha, Rails on my setup FYI.

load's callback argument doesn't work

at least as far as i can tell, load(uri, cb) never calls cb() because load passes it to addToContainer, which ignores it.

Split the various types of fixtures loading

javascript fixtures should be loaded in a different way from html fixtures. That way, browsers can correctly execute javascript that was injected through the iframe body.

Without this enhancement, subsequent attempted javascript fixtures will not actually execute:

    fixtures.load('path-to-html-fixture');
    fixtures.load('path-to-js-fixture'); // will not execute

In a related note, attempting to fix #8 caused all the inline-javascript tests to break. The only reason those tests worked is because they were injected into the head and not the body.

The api would look something like this:

    fixtures.load('path-to-html-fixture');
    fixtures.loadHTML .... // alias
    fixtures.loadJS
    fixtures.loadJSON
    ....

By splitting the api, it will behaviorally allow me to create the corresponding <script> element and allow them to be executed/injected in the <head>.

This would also round out #9 nicely.

This enhancement would perhaps warrant a major version bump since it will somewhat break existing tests.

Why not a hard fork?

Hi there,

I found your fork through a Stackoverflow broken url and I think this should be really a project by itself, so that it can be promoted like that. As a Github fork you don't appear in search results and the visibility of the project is minimum. We are porting some tests from Jasmine to Mocha and using js-fixtures happily, thanks.

One little detail, I would state very clear the differences between the API in the top part of the README. Something like:

readFixtures is now fixtures.read()
setFixtures is now fixtures.set()

Cheers,
Miguel

Allow fixtures to define fixture area HTML node type

I had a problem yesterday whereby my existing Jasmine-jQuery fixtures were not accessible to my tests; I discovered this was because they were loading inside the iframe.

I have modified the code to include a "type" (same method as with "path"), but I have also modified the other instances in the code that would expect an actual window/document instead of a normal HTML node.

This seems to work, I am unsure what the "cb" function is in the createContainer function, otherwise I'd like to be able to commit this.

The reason I have done this is because Karma is already configured to load the necessary resources I need, and I am writing tests for scripts that would normally be loaded in a normal webpage. My fixtures are very short HTML snippets, and are designed primarily to be copied into the same context as the included scripts (as with jasmine-jquery) - however we are moving away from Jasmine in favour of a more configurable Mocha framework - if you believe this request to be out of context or lacks reason, please respond!

Ability to load json fixtures

sandbox test fails on Firefox 24 and 27 in js-fixtures 1.3.1

accepts booleans, numbers, and string

expected '<div data-blah="3" selected="true" class="blah"></div>' to equal '<div class="blah" selected="true" data-blah="3"></div>'
Assertion.prototype.assert@http://localhost/r/js-fixtures-1.3.1/node_modules/expect.js/expect.js:99
Assertion.prototype.equal@http://localhost/r/js-fixtures-1.3.1/node_modules/expect.js/expect.js:203
@http://localhost/r/js-fixtures-1.3.1/test/fixtures-spec.js:186
Runnable.prototype.run@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4212
Runner.prototype.runTest@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4584
next/<@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4630
next@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4510
next/<@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4519
next@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4463
Runner.prototype.hook/<@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:4487
timeslice@http://localhost/r/js-fixtures-1.3.1/node_modules/mocha/mocha.js:5480

Quick guess is that Firefox is serializing the HTML attributes in a different order, which should, in theory, be valid. If that's correct, presumably the thing to do is to make the test a bit more robust.

Add Scaffolding

Setting up mocha in the browser is a bit of a pain in general. It'd be a good idea to include some example scaffolding. It'd also be nice to add in some more specific use-cases like developing a jquery plugin, etc.

tag new version and publish to Bower

Last tag is over one year old and there are still Jasmine deps. Please tag new version, so people can load latest code via Bower. Also publishing to Bower is good idea - people can find project via bower-components.

Update dependencies (especially mocha)

Hi,
when running npm install on the current master branch, I get several warnings that dependencies are outdated:

$ npm -v
6.4.1
$ node -v
v8.12.0

$ npm install
npm WARN [email protected] No license field.

audited 21 packages in 1.343s
found 2 vulnerabilities (1 high, 1 critical)
  run `npm audit fix` to fix them, or `npm audit` for details
ohmsk@oc0372304483:~/git/rba/js-fixtures (master)$ npm audit
                                                                                
                       === npm audit security report ===                        
                                                                                
# Run  npm install [email protected]  to resolve 2 vulnerabilities
SEMVER WARNING: Recommended action is a potentially breaking change
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Regular Expression Denial of Service                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ minimatch                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mocha                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mocha > glob > minimatch                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/118                       │
└───────────────┴──────────────────────────────────────────────────────────────┘


┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Critical      │ Command Injection                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ growl                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ mocha                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ mocha > growl                                                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/146                       │
└───────────────┴──────────────────────────────────────────────────────────────┘


found 2 vulnerabilities (1 high, 1 critical) in 21 scanned packages
  2 vulnerabilities require semver-major dependency updates.


$ npm ls
[email protected] /home/ohmsk/git/rba/js-fixtures
├── [email protected]
├─┬ [email protected]
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ └─┬ [email protected]
│ │   ├── [email protected]
│ │   └── [email protected]
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ └── [email protected]
├── [email protected]
└─┬ [email protected]
  └─┬ [email protected]
    └── [email protected]

$ npm outdated
Package    Current  Wanted  Latest  Location
expect.js    0.2.0   0.2.0   0.3.1  js-fixtures
mocha       1.17.1  1.17.1   5.2.0  js-fixtures
requirejs   2.1.22  2.1.22   2.3.6  js-fixtures
sinon        1.4.2   1.4.2   6.3.4  js-fixtures

Could you please update the dependency to mocha to remove the findings?

Thanks in advance
Konrad

Allow fixtures to load templates

It would be awesome if fixture support allowed you to plug in various client-side templating engines like jade, haml, ejs, etc.

Accessing HTML fixture

Hey,

maybe I'm not understanding how to use this library correctly but I can't seem to get it work with my JS libraries. I'm finding that because my fixture HTML is added within the iframe it can't access it.

For example,

I have an AMD module which looks something like this:

define(['jquery', 'rotatorPlugin', function($){
   return {
      init: function(){
        $('#my-rotator-fixture').rotatorPlugin();
      }
   };
});

I then have a spec like this:

define(['jquery', 'app/ui/rotator'], function($, Rotator){
    describe('the Rotator Module', function() {
        it('should correctly init the rotator on the page', function() {

            //Setup
                        fixtures.load('rotator.html');
            $rotator = $('.js-rotator');

            //Work
            Rotator.init();

            //Assertion
            expect($rotator).to.have.data('rotatorPlugin');
        });
    });
})

I'm finding though that in my spec and Rotator module when running $('.js-rotator').length it returns0 unless I specifically target the iframe. Is this what should be happening? This is a very simplified example, I know, but by not having access to the fixtures outside of the iframe does this mean I have to pass in all the DOM elements I want to test in my AMD modules?

Thanks,
Pat