I am working on converting a Backbone application into an Ember application using Ember Data. It works fine in the browser but the Jasmine test cases will not pass. When I try to create a record in the Jasmine test case I get this error:
TypeError: 'undefined' is not a function (evaluating 'type._create({ store: this })') in http://localhost:8888/spec/javascripts/generated/assets/application.js (line 26874)
This is the actual code that the error message points to:
createRecord: function(type, properties, transaction) {
properties = properties || {};
// Create a new instance of the model `type` and put it
// into the specified `transaction`. If no transaction is
// specified, the default transaction will be used.
//
// NOTE: A `transaction` is specified when the
// `transaction.createRecord` API is used.
var record = type._create({
store: this // line 26874
});
The actual code that the test case is executing looks like this:
nutrient = App.Nutrient.createRecord({"name_min":"nut 1","female_31_50_min":7.5,"male_31_50_min":8.0,"created_at":"2011-10-10T01:31:53Z","female_51_70_min":8.5,"updated_at":"2011-10-12T12:28:35Z","male_70_plus_min":10.0,"female_19_30_min":6.5,"child_4_8_min":4.0,"male_19_30_min":7.0,"lactating_14_18_min":5.75,"infant_0_05_min":1.0,"female_70_plus_min":9.5,"pregnant_14_18_min":5.8,"infant_6_12_min":2.0,"id":1,"male_9_13_min":5.0,"child_1_3_min":3.0,"female_9_13_min":4.5,"female_14_18_min":5.5,"male_14_18_min":6.0,"lactating_31_50_min":7.75,"pregnant_31_50_min":7.8,"pregnant_19_30_min":6.8,"male_51_70_min":9.0,"lactating_19_30_min":6.75,"female_31_50_max":8.5,"male_31_50_max":9.0,"female_51_70_max":9.5,"male_70_plus_max":11.0,"female_19_30_max":7.5,"child_4_8_max":5.0,"male_19_30_max":8.0,"lactating_14_18_max":6.75,"infant_0_05_max":2.0,"female_70_plus_max":10.5,"pregnant_14_18_max":6.8,"infant_6_12_max":3.0,"male_9_13_max":6.0,"child_1_3_max":4.0,"female_9_13_max":5.5,"female_14_18_max":6.5,"male_14_18_max":7.0,"lactating_31_50_max":8.75,"pregnant_31_50_max":9.8,"pregnant_19_30_max":7.8,"male_51_70_max":10.0,"lactating_19_30_max":7.75})
person = new App.Person.createRecord({age: 0.25})
expect(nutrient.requiredNutrientForPerson(person)).toEqual({min_amount: 1.0, max_amount: 2.0})
Any ideas would be appreciate.
In general, if you're having problems with a test that you don't experience in the browser, it's because the tests are running outside of the Ember run loop.
Try calling Ember.run.sync() before expect() to force synchronization. Alternatively, place any code that involves binding in an anonymous fn inside: Ember.run(function() { }).
Check out the ember and ember-data source for other testing examples, since coverage is pretty solid.
With that said, I'm not an ember-data expert, so I'm not sure if this is the problem you're experiencing.
Sorry, My Bad. The problem is with this line:
person = new App.Person.createRecord({age: 0.25})
I needed to remove the new keyword and it worked correctly
Related
I am the developer of this Vue.js Plugin and am currently working on the test for v1.0.0, using already written tests for older versions with some adjustments.
Scenario
Test the components with the following structure:
// receives props and passes through
VueEllipseProgress
// receives props, adds new and passes through
EpCircleContainer
// receives props and do main SVG rendering
CircleProgress
Use Factory function:
// this is the top level VueEllipseProgress component
import Container from "../../../src/components/VueEllipseProgress.vue";
import Circle from "../../../src/components/Circle/CircleProgress.vue";
const factory = propsData => {
return mount(Container, {
propsData: {
...propsData
}
});
};
const wrapper = factory({...})
Use wrapper.setProps() in the test to apply new props. Test, how changed props affect the rendering of SVG elements on the other end. You can see the whole code on GitHub.
Problem
wrapper.setProps() updates the props of the VueEllipseProgress (top level) correctly and wrapper.vm.$props has the expected values. But the props of CircleProgress component remain unchanged, HTML still not updated. This leads to test failures.
it("do some test", () => {
/* do some test here, all is fine */
wrapper.setProps({ someProp}); // set new props
wrapper.vm.someProp; // updated
circleWrapper.vm.someProp; // still old
// fails!!!
expect(circleWrapper.element.getAttribute("someProp")).to.equal(someProp);
});
Here are more code details related to above example.
Note, that the plugin works correctly live and all props are reactive.
The test worked for earlier versions of my plugin. In the meantime i have updated #vue/cli to version 4.x.x. Maybe the failures are related to this update, but I couldn't find any information in the release notes that could confirm this.
This is not the direct solution, more a tip to avoid the problem. In my components, I use v-binde="$props" to propagate the props to subcomponents. However, this can cause issues with jsdom, like in my case.
I ended up with refactoring all my tests by testing each komponent directly, avoiding the need of nested structure and props propagation (like unit tests are supposed to be).
I have a component that expects a model property that is an ember data object (originally created from the route model)
I've tried this in the integration test but the store is undefined
test('it renders', function (assert) {
this.inject.service('store')
let model = this.get('store').createRecord('post');
this.set('model', model);
this.render(hbs`{{post-item-form model = model}}`);
assert.equal(this.$().text().trim(), 'Post your thoughts');
// Template block usage:
this.render(hbs`
{{#post-item-form}}
template block text
{{/post-item-form}}
`);
// assert.equal(this.$().text().trim(), 'template block text');
});
I would prefer to create a pure json object instead of creating a record through the usage of store in a component integration testing; because the component itself knows nothing about the store and you can just pass pure json object instead of a model instance to the component and it should still work. With this mindset, I would only deal with store in acceptance tests.
If you still would like to go the way you have mentioned; I believe you need to retrieve the store as follows:
var store = Ember.getOwner(this).lookup("service:store");
Since; auto run loops are disabled in testing mode by default; it is most likely that you will get an assertion error indicating that there is no run loop available when you run the following code let model = store.createRecord('post'); this means you need to wrap it in a within a run loop like Ember.run(()=>model = store.createRecord('post'));. I did not give a try to what I wrote; but I guess this should work.
Yet again; why do you need to create the record through store in an integration test? If you really like to use store; then an acceptance test should be better; since store will be up and running and you will not need to retrieve it through lookup. I hope this helps.
I've set up an error substate route/controller/template according to http://guides.emberjs.com/v2.2.0/routing/loading-and-error-substates/. Manually browsing my app, I can trigger error conditions and get directed to the substate. Confirmed with Ember Inspector.
I'd like to automatically test the substate. However, Ember CLI's test runner fails any test when a route's model hook rejects. In other words, the test fails before I can navigate to the error substate.
How can I automatically test my error substate?
Ember: 2.2.0
Ember CLI: 1.13.13
Unfortunately it doesn't seem to be easy to do this in a clean manner.
In its internal tests, Ember uses bootApplication to the route which errors (see github) and is able to directly catch the error. Unfortunately if you try and do any form of try/catch or then/catch around a call to visit in your tests you will find it fails.
When you visit a link which results in an error substate from your acceptance test then Ember's defaultActionHandlers.error gets fired. By design it is not meant to be overridable. It calls logError which calls Ember.default.Logger.error.
So to test this substate we need to temporarily overwrite that method. We can also peek inside the ember container to access the currentRouteName like so (using sinon for the spying):
test('when there is an API error an error message is shown', function(assert) {
const emberLoggerError = Ember.Logger.error;
Ember.Logger.error = sinon.spy();
visit('/users/');
andThen(() => {
// This could be nicer and less private with `getOwner`
let { currentRouteName } = this.application.__container__.lookup('router:main');
assert.equal(currentRouteName, 'users.index_error', 'The current route name is correct');
assert.equal(Ember.Logger.error.callCount, 1, 'The error logger was called');
// Restore the Ember.Logger
Ember.Logger.error = emberLoggerError;
});
});
Things can get even more complicated though. If your visit happens inside a Promise (it did in our case because we were using ember-page-object for our tests) then you have more to deal with...
In a separate loop onerrorDefault of RSVP is triggered which calls Test.adapter.exception AND Ember.default.Logger.error (again!) - passing the stack. So in this case you need to stub and spy on Test.adapter.exception and expect Ember.default.Logger.error to have been called twice!
Am fairly new to the world of testing MVC 4 Web Applications and have been attempting to unit test views and controllers to see whether for a given controller that an action renders a particular view, I have been using MvcContrib TestHelper to try to simply the process of testing the application but so far have been unable to get the test to pass.
When the test is run I receive the error Expected view name was 'index' actual was ''
Currently I am running this test method:
[TestMethod]
public void AMAC_Controller_Renders_Index_View()
{
var builder = new TestControllerBuilder();
var controller = new AMACController();
builder.InitializeController(controller);
var result = controller.Index();
result.AssertViewRendered().ForView("index").WithViewData<AMACEnquiryModel>();
}
the controller and model are both currently in use by the application, was wondering if you could give any advice on how get this test working, I have modified previously when I have done this I get another error that the route name already exists in the collection.
After getting some advice from one of the contributors of the MvcContrib project the reason the test wasn't passing was because I was passing the wrong data into the .ForView(), before I had .ForView("index") where the controller was actually passing View(model) so the value for .ForView() was actually an empty string so the assert now looks like this:
result.AssertViewRendered().ForView("").WithViewData<AMACEnquiryModel>();
Day 2 learning ember.js...
I'm working on a offline app that needs to save draggable/sortable tile positions to localstorage, and if there is no existing data, load & save from a fixture.
Using: ember 1.0.0-pre4, ember-data rev11, ember-localstorage-adapter, jQ 1.9, jQ UI 1.9
https://github.com/rpflorence/ember-localstorage-adapter
It's working, but I'm a bit of a novice, feel it's not pretty and could use some community advice.
http://jsfiddle.net/Nsbcu/4/
Questions
What is the proper way to check if your DS.Store has loaded and is empty? My method of looking directly at localstorage didn't feel right.
After I createRecords from the App.Tile.DEFAULTS I feel I should commit them, but an error is thrown. I don't have to commit the known defaults, but curious what causes the error and how I should go about committing properly. Also is the App.ready() callback the right place for loading defaults? Error only happens when localstorage is empty
Uncaught Error: Attempted to handle event loadedData on <App.Tile:ember231:1> while in state rootState.loaded.created.inFlight. Called with undefined
On the TilesController I'm using sortProperties which works great until jQ UI Sortable changes the DOM and Ember wants to update my tile order, before I get a chance to set the new order. My current solution is to turn off sortProperties temporarily while updating the model. Again this feels hacky, suggestions on proper way to do this?
=== Edit Feb 3 ===
If I do an async commit the initial error in question #2 is avoided.
App.TilesRoute = Ember.Route.extend({
model: function() {
return App.Tile.find();
},
setupController: function(controller) {
if (localStorage.getItem('fusion-emberjs') == null) {
App.Tile.DEFAULTS.forEach(function(item) {
App.Tile.createRecord(item);
});
// Commit async, else generates error
var _this = this;
setTimeout(function() {
_this.store.commit();
}, 1);
}
}
});
I would put any initial code inside the application or the index Route within the setupController method
if (localStorage.getItem('fusion-emberjs') == null) {
App.Tile.DEFAULTS.forEach(function(item) {
App.Tile.createRecord(item);
});
//*** WARNING: Generates Error ***/
App.Tile.find().get('store').commit();
}
Once you move the code inside the route, replace App.Tile.find().get('store').commit(); by App.store.commit() inside your route
Create your own transaction instead of using the default one, each time you make a call to the store directly you're using the default transaction. You can create a transaction this way
var transaction = App.store.transaction()
transaction.createRecord(App.Foo);
transaction.commit()
transaction.rollback();
Any call to App.store assumes you already created a store, right now you're only extending the DS.Store. Try instead
App.Store = DS.Store.create({
revision: 11,
adapter: 'App.LSAdapter'
});
I would suggest that you do any event handling or transaction management in the router unless it's purely for styling or animation. In that case, the view is the right place for it. I like the router to orchestrate communication between all the assets (controllers, routes, models, views)
A good pattern to remember is a view talks only to a controller, a controller is a mere proxy to a model, a router orchestrates communication between controllers and manages routes.