I see a lot of examples (including ember-cli generated tests) that use assert.function() but I can use the function as is, so am I doing something wrong, or do examples just show not-really-necessary qualifiers?
For example, either of these work in a new generated unit test:
assert.expect(1);
expect(1);
Why ever do the first one if the second one works?
This is actually a QUnit change, not an Ember one. QUnit is changing their API as they move towards 2.0. You can use the global versions now, but they'll be removed in 2.0 so it's probably a good idea to use the assert.* versions now so you don't have to change the code later.
Related
I have an Ember app that uses several 3rd party add-ons. One of these add-ons uses Object.assign() which causes problem in IE11, specifically the error
Error: Object doesn't support property or method 'assign'
I know why this is happening, but I'm relatively new to Ember, and am not sure of the best way to handle/fix this. Based on my research, some options are:
Option 1: use polyfills (?)
I think there may be some additional libraries I can install, or options in Babel to set that will take care of this, but I have not been able to do so thus far. It's unclear whether any of these options would affect code from add-ons anyway, or if they only apply to code in the primary app.
Option 2: extend the add-on component to avoid Object.assign().
Unfortunately, the problematic lines are in the component's init(). When my extended component calls this._super(), the code I'm trying to avoid is run anyway. Is there a way to 'skip' the base component's init() and go straight to Ember's Component.init() (the add-on's _super()) ?
Option 3: ditch the 3rd party add-on, salvage what I can, and make my own component.
Irritating but do-able. At this point, it probably would have been faster to do that from the start.
Option 4: fix the add-on to remove the problem code. My hesitation here is two fold: 1, if this is something that I should somehow be managing within my app, it doesn't seem correct to make the add-on change (though there is definitely a 'best practices' argument to be made here). The bigger concern is that this is a low activity add-on. Even if I submit a PR with the change, I'm not sure how long it will take for a new release.
In the meantime, what would be the recommended practice? Point my app to a local build and then remember to update it to an 'official' version if/when it is released?
I suspect that Option 1, polyfills and/or build settings, is the most correct course of action, but I'm at a loss for what, specifically, to do.
Additional info:
My app was developed with Ember 2.7, and I am in the process of updating it to Ember 3.1. This issue exists in both builds.
You can include polyfill:
// ember-cli-build.js
let app = new EmberApp(defaults, {
'ember-cli-babel': {
includePolyfill: true
}
});
I'm writing tests for a React application which makes use of Fluxxor to provide an event dispatcher. Making that work requires telling Jest not to mock a few modules which are used internally, and are provided by Node itself.
That means I can't just add them to the unmockedModulePathPatterns config key, and instead have to use some code like this:
[ 'util', 'events' ].forEach(function (module) {
jest.setMock(module, require.requireActual(module));
});
However, I can't find anywhere useful to put it. I've got a setupEnvScriptFile which sets up a few globals that I use in almost all my tests, but the jest object doesn't seem to be available in that context, so I can't just set the mocks there.
As a hacky stopgap measure I've wrapped the code above in a function which I call at the beginning of any describe blocks testing Fluxxor stores, but its far from ideal.
Have you tried config.setupTestFrameworkScriptFile? Seems like it would be the right place to monkey patch the api, as per the docs.
It seems that the answer, at least currently, is "you can't in this case", but there are issues open for the two changes that need to be made to support it.
https://github.com/facebook/jest/issues/106
https://github.com/facebook/jest/issues/107
FWIW, Here's a solution that we have been using to add Fluxxor and React-Router support to our test specs.
https://gist.github.com/adjavaherian/a15ef0461e65d58aacd2
I am currently looking into the meteor framework and this question immediately jumps to mind.
Is code which I write (for example Template.xxx code or Template.xxx.events) actually testable in any way?
Of course you can test code which is not bound to the meteor runtime as you would any other code, but my impression is that most code you will write inside of meteor is somehow scoped to meteor and its functions.
There doesn't seem to be any official test framework yet apart from the undocumented Tinytest (see the video tutorial) and its helpers, but you can always stub/mock out the Meteor framework API like I've done in this trivial example on github.
I imagine it could get a lot harder for non-trivial applications, so it's probably a good idea to separate core application logic away from Meteor API calls.
As of February 2014, Meteor code is unit-testable using the built-in Tinytest framework, as long as you move all your application code into packages, which you should do anyway. The quick-and-dirty way amounts to adding a package.js file. That file serves to:
Declare your exports. It's good practice for clean namespacing to have one global object for your app
Declare your test files
Here is an example by Eventedmind - https://github.com/EventedMind/meteor-file
You can see in meteor-file-test.js that it accesses MeteorFile, which is declared as an export in package.js.
I think it is testable although I haven't looked into it too deeply.
If you open up the liveui package ($METEOR_HOME/packages/liveui) there seems to be quite a few unit tests written using TinyTest and testing the rendering. I think that would be a good place to start:-
liveui_tests.js
liveui_tests.html
etc.
Hope that helps
I've created a blog post here showing how to do effective unit testing in Meteor, along with an example project on GitHub. Hope it helps.
http://blog.xolv.io/2013/04/unit-testing-with-meteor.html
Velocity has been selected as the official testing framework for meteor 1.0. The announcement has been made in the last meteor devshop (june 2014).
Packages developed with velocity:
velocity (the test runner)
jasmine-unit (jasmine syntax)
mocha-web-velocity (for testing collections)
velocity-html-reporter (view the tests in the browser)
I've been trying to rework an as yet unfinished ember app of mine to use require.js
It's mainly for interest value and I started looking into it when I wanted to use require-text for my handlebar templates, for convenience. So I havent found myself looking into it for any sort of AMD related performance win or anything like that. But now I've started setting my module out by defining modules I am finding it easier to read and would like to stick with it.
There is a question on stack overflow where the asked has come back and posted their findings Ember.js and RequireJS but none of the other examples, like the example on todo MVC can be found on references on how to optimally structure and reference the files in more complex apps.
So anyway, my question is: What are the rules to follow to make correct use of require JS. What does it achieve (apart from access to AMD)? It's hard for me to get my head around it with a test project that doesnt really require it, but I'd like to learn the correct ember related principles so I can use it in future.
I've seen from example code that the idea may be to remove all references to the global namespaces from the modules. Is that correct? There arent enough examples around for me to spot a pattern.
At the moment a file at the top level of my structure might have some stuff like this in
<script>
define(['jquery',
'app/controllers/mailshotlist',
'app/controllers/sites',
'ember'],
function($, MailShotList, Sites) {
var App = Em.Application.create({
Views: Em.Namespace.create(),
Models: Em.Namespace.create(),
Controllers: Em.Namespace.create(),
init: function() {
this._super();
this.Controllers.set('Sites',Sites.create());
this.Controllers.set('MailShotList',MailShotList.create({
sitesControllerBinding: 'App.Controllers.Sites'
}));
}
});
return window.App = App;
});
</script>
So, trying to stitch together explicit app.x references in initialisation of the app. Since I guess if your modules are all referencing each other explicitly in the code then its not properly modular. I'm not at the stage where i want to reuse modules at the moment, but im assuming that is one of the goals
I'd like for this not to turn into a debate about whether AMD is worth it or not, my question is specifically about what rules need to be followed to get the most out of using ember with require js. Although if there are good specific reasons for not using ember with require then that would be interesting.
I think I've rambled a bit and am running the risk of getting this locked as 'non-productive' but If you can understand my question and what im trying to understand (or if im barking up the wrong tree entirely) then please post a reply
Haven't made up my own opinion yet but this is what Ember.js developer Tom Dale has to say on the matter.
http://tomdale.net/2012/01/amd-is-not-the-answer/
If you still want to use EmberJS and RequireJS,
I've just uploaded to github a starter-kit for EmberJS+RequireJS, You could check it https://github.com/fernandogmar/Emberjs-RequireJS
It's my particular suggestion for big enough projects...
Any good suggestions will be highly appreciated. Have Fun!
There is nothing that makes emberjs / requirejs relationship special , they are orthogonal. Does Ember solves dependencies between script files ? no , Is requirejs a MVC framework ? no , so what is the problem ? The use of requirejs with emberjs is no different from the use of requirejs with any library that doesnt provide AMD. So nothing special here. You want AMD ? use requirejs to define your own modules and resolve dependancies between them , that's the point.
The only question is , do you have a problem to solve or not ?
As #mpm wrote, there is nothing special about Ember.js + RequireJS or other no-AMD framework + RequireJS.
Good starting point is RequireJS documentation and Ember.js + RequireJS TodoMVC project example:
http://requirejs.org/docs/start.html
http://addyosmani.github.com/todomvc/
For all the things I love about Grails I do have one small issue and this isn't really even a Grails specific problem. GSP changes require redeployments of the entire web application. I'm not talking about adding new dynamic data or major changes. These generally requires server side changes as well anyway.
But I'm talking about smaller changes like flipping the position of a couple of elements or modifying some simple static text on the page. So my question is, what are some patterns used or plugins, etc that allow minor changes to GSP's without redeploying the entire application? How can I make Grails template/GSP's more like templates and less requiring compiling?
I'm also possibly looking for something more designer friendly.
grails.gsp.view.dir, I think.
A trick to remember: add trailing slash and remember that grails-app/views will be added to it.
There is a Grails Plugin for using FreeMarker templates as views (I have not used this plugin myself). It is not listed as SpringSource supported, but I think the author is one the core grails devs and the plugin is based on a relatively new version of FreeMarker.