[2.0] Fix loopback in PhantomJS, fix karma tests

[bajtos]

• Move configuration of Karma unit-tests from Gruntfile.js to a
  standalone file (test/karma.conf.js).
• Add a new Grunt task karma:unit-ci to run Karma unit-tests in
  PhantomJS and produce karma-xunit.xml file that can be consumed
  by the CI server.
• Add grunt karma:unit-ci to the test script in package.json.
• Add es5-shim module to karma unit-tests in order to provide
  ES5-methods required by LoopBack.
• Fix mixin(source) in lib/loopback.js to work in PhantomJS.
  Object.getOwnPropertyDescriptor() provided by es5-shim does not
  work in the same way as in Node.

Requires loopbackio/loopback-datasource-juggler#152

/to @ritch Please review.
/cc @rmg When this patch is landed, loopback is ready to run karma unit-tests on our Jenkins. npm test is already running karma via Grunt, is there anything else needed to enable karma tests on Jenkins?

[rmg]

@bajtos you can test what Jenkins will do by using sl-ci-run locally.

What kind of report is generated by the karma tests?

[bajtos]

@rmg I am always forgetting about sl-ci-run. Ok, the Karma tests were run. The output is karma-xunit.xml in the project root dir.

[ritch]

Isn't this breaking?

[bajtos]

AFAIK it is not breaking. This check is preventing the following situation:

$ node
> Object.defineProperty({}, 'foo', undefined)
TypeError: Property description must be an object: undefined
    at Function.defineProperty (native)

desc is not defined when the key is not an own property of the source. MDN on getOwnPropertyDescriptor:

Return value
A property descriptor of the given property if it exists on the object, undefined otherwise.

What happens in PhantomJS:

• for (var key in source) enumerates over bind function
• the bind function is not an own property, getOwnPropertyDescriptor returns undefined
• Object.defineProperty throws when the descriptor is not defined

[ritch]

@bajtos Are we including the es5 shim when not running the tests (eg. when built by browserify)?

[rmg]

karma-xunit.xml will be picked up by CI, but I have a feeling the xunit.xml file is no longer generated.

[rmg]

test please

[bajtos]

@ritch Are we including the es5 shim when not running the tests (eg. when built by browserify)?

No. Most browsers support ES5 these days, with the exception of Internet Explorer 6-8.

yo angular is adding a conditional include to the generated index.html file:

    <!--[if lt IE 9]>
    <script src="bower_components/es5-shim/es5-shim.js"></script>
    <script src="bower_components/json3/lib/json3.min.js"></script>
    <![endif]-->

Even if this was not the case, including ES5 shim in the browserified bundle would not be a good idea, as it would unnecessarily increase the size of the browser bundle for all browsers.

I suppose this matter should be described in the documentation. The docs should mention that loopback depends on ES5 and users should load ES5-shim to run it in a browser that does not implement ES5.

/cc @crandmck

[bajtos]

@rmg I have a feeling the xunit.xml file is no longer generated.

Yes, that's correct. I tried to change the test script to mocha && grunt karma:unit-ci, but it did not help. What do you advise?

[ritch]

Even if this was not the case, including ES5 shim in the browserified bundle would not be a good idea, as it would unnecessarily increase the size of the browser bundle for all browsers.

Sure.

I suppose this matter should be described in the documentation. The docs should mention that loopback depends on ES5 and users should load ES5-shim to run it in a browser that does not implement ES5.

We should have a guide for using loopback in browsers that includes this.

[rmg]

@bajtos the Gruntfile could have a top-level test task that runs tests based on the environment. It could check for $JENKINS_HOME and tell karma and mocha to generate xunit test reports (matching **/*xunit.xml) and produce a more developer friendly output when not under CI. I tried to avoid the need for that with the build framework our CI uses, but multiple test runners makes the automatic detection/replacement for overriding reporters more complicated.

[bajtos]

@rmg that sounds plausible, I'll look into it tomorrow. thanks!

[bajtos]

@rmg @ritch I have implemented grunt test task in the commit above, could you please review?

[rmg]

@bajtos it looks like I'll have to make changes to sl-ci-run so that it doesn't assume mocha and bypass npm test. If you could make mocha-and-karma the name of the task it should work without modifying sl-ci-run. In the future it might also be useful to use mocha-jenkins-reporter but that shouldn't be necessary right now.

[bajtos]

@slnode test please

[bajtos]

grunt mocha-and-karma seems to work well.