I have been trying to test my ember application for 2 days with no success. There are examples out there that use fixtures but I was wondering if you might have an example of test scripts where RESTAdapter was used. I have tried using Fixtures for testing as you can see in the fiddle here : http://jsfiddle.net/deewen/u68Mx/1/, but that is also not working for me(sorry I couldn't find proper expect.js file).
it("Check analyticsRuns controller", function () {
//var controller = AS.__container__.lookup('controller:analyticsRunsIndex');
//the returns null too even though I have that controller
visit('/analytics')
.then(function() {
expect(find('*')).to.not.be(undefined);
});
});
Any suggestions for resource or read that could guide me on this would be highly appreciated. Thanks.
In general you don't want your test to hit a live API endpoint because at that point you're not only testing your application code, you're also testing both the functionality of the API and the state of any data that may (or may not) already be stored in the API service.
The Ember Data tests setup fake AJAX responses, much like you'd do with something like webmock on the server side. Something like that is probably the way to go.
https://github.com/emberjs/data/blob/master/packages/ember-data/tests/integration/adapter/rest_adapter_test.js#L34-L55
Related
I need to do integration tests for my Ember app, for example in the user template :
<div class="container">
<h1>{{model.firstName}} {{model.lastName}}</h1>
<p>Age: {{model.age}} years old</p>
<p>Job: {{model.job}}</p>
<img src="{{model.image}}" alt="img" id="image">
</div>
I have to test that the list of users is correctly displayed. Is it possible to do so ?
I have never done that and I'm kind of lost here. Would it be something like :
test('it renders all users', function(assert) {
this.set('users', [
{ firstName: 'Tubby'},
{ firstName: 'Spot'},
{ firstName: 'Chester'},
{ firstName: 'Frisky'}
]);
this.render(hbs`{{user users=users}}`);
assert.equal(this.$('.user').length, 4);
});
Even though I read many articles about the integration tests, I still don't understand if it can be used for something that is not a component.
What about redirection ? Let's just say that I have to write an integration test that verifies that the redirection is okay. Can I do that with integration tests ?
Thanks for your help.
It may be worth doing a quick review of the testing options:
Unit tests allow us to test small chunks of code. Things that are easy to test this way would be services, serializers or adapters.
Integration tests are primarily designed to let you test components and the way they work together and interact with users. Things often tested include events of different sorts (clicks, keystrokes, etc) and the way a component reacts to different types of data.
Acceptance tests are often used for testing the integrated whole of your app (pretending to be your user and browsing the site).
Often, checks for redirects would either be an acceptance test. You could also do unit tests (if you have complicated route logic that handles various scenarios that redirect). Testing redirects in an integration test would primarily focus around making sure clicking a button would attempt to redirect somewhere else.
Does that help?
I hope, The below tutorial will help you to understand the test case. The tutorial has examples for all testing(UNIT, Acceptance and Integration).
https://medium.com/#srajas02/ember-test-case-for-a-crud-application-with-mirage-d6d9836bfee2
Source Code: https://github.com/srajas0/ember-test-cases
I'm still a bit new to Ember. I'm using Ember 1.13 with Ember Data and the DS.RESTAdapter. For debugging purposes, as well as educational (such as getting a feel for how Ember Data works with various options such as the shouldReload* functions), I want to log every API request with mainly the URL called and optionally how it was called (eg, from a store.findAll() or store.queryRecord(), etc.). Is there a single place (my guess is somewhere in adapter:application?) where I can put a single console.log('URL called: ', url, ', from: ', callingFunction); that handles all of this?
If you use the JSONAPIAdapter or the RESTAdapter just override ajax() on the adapter to log the URI:
ajax(url, type, options) {
console.log(url);
return this._super(...arguments);
}
There is no easy way to get the caller function. Analyse the callstack, if its just for debugging purposes!
But, maybe just use the Browser log XMLHttpRequest option if its for debugging?!
If you want to know how it works, checkout the code. The adapter and the store is where you can look for knowledge.
I've read lots of documentation about testing controllers using $this->call($destination, $parameters, 'GET'); but this seems to rely on the route being set up too, and knowing the right $destination to use.
Generally this is OK, but accessing a controller from a route doesn't seem right for unit testing. I want to unit test the controller, not the route. Is there a standard way to unit test controllers, without dealing with routes?
Is simply manually instantiating the controller and calling the method enough? E.g.
$controller = new MyController;
$response = $controller->someMethod($param);
$this->assertSomething($response);
Perhaps controllers shouldn't be unit tested (and only have acceptance tests) and my request is a sign that my controllers are too heavy.
You can call your actions directly:
$response = $this->action('GET', 'OrdersController#show', ['id' => 1]);
The action method has been removed from Laravel 5.4 testing api
In laravel 6 any controller method can be called directly as follows:
app()->call('App\Http\Controllers\TestController#testMethod', [$param1, $param2]);
that's it.
I have a number of simple controller classes that use Doctrine's entity manager to retrieve data and pass it to a view.
public function indexAction() {
$pages = $this->em->getRepository('Model_Page')->findAll();
$this->view->pages = $pages;
}
What exactly should we be testing here?
I could test routing on the action to ensure that's configured properly
I could potentially test that the appropriate view variables are being set, but this is cumbersome
The findAll() method should probably be in a repository layer which can be tested using mock data, but then this constitutes a different type of test and brings us back to the question of
What should we be testing as part of controller tests?
Controller holds core logic for your application. Though simple "index" controller actions don't have any specific functions, those that verify/actively use data and generate viewmodels have pretty much the most functionality of the system.
For example, consider login form. Whenever the login data is posted, controller should validate login/password and return: 1) to index page whenever logins are good. Show welcome,{user} text. 2) to the login page saying that login is not found in db. 3) to the login page saying that password is not found in db.
These three types of outputs make perfect test cases. You should validate that correct viewmodels/views are being sent back to the client with the appropriate actions.
You shouldn't look at a controller like at something mysterious. It's just another code piece, and it's tested as any other code - any complicated logic that gives business-value to the user should be tested.
Also, I'd recommend using acceptance testing with framework like Cucumber to generate meaningful test cases.
Probably the controller is the hardest thing to test, as it has many dependencies. In theory you should test it in full isolation, but as you already seen - it has no sense.
Probably you should start with functional or acceptance test. It tests your controller action in a whole. I agree with previous answer, that you should try acceptance testing tools. But Cucumber is for Ruby, for PHP you can try using Codeception. It makes tests simple and meaningful.
Also on a Codeception page there is an article on how to test sample controllers.
I'm trying to write unit tests for parts of my Node app. I'm using Mongoose for my ORM.
I've searched a bunch for how to do testing with Mongoose and Node but not come with anything. The solutions/frameworks all seem to be full-stack or make no mention of mocking stuff.
Is there a way I can mock my Mongoose DB so I can return static data in my tests? I'd rather not have to set up a test DB and fill it with data for every unit test.
Has anyone else encountered this?
I too went looking for answers, and ended up here. This is what I did:
I started off using mockery to mock out the module that my models were in. An then creating my own mock module with each model hanging off it as a property. These properties wrapped the real models (so that child properties exist for the code under test). And then I override the methods I want to manipulate for the test like save. This had the advantage of mockery being able to undo the mocking.
but...
I don't really care enough about undoing the mocking to write wrapper properties for every model. So now I just require my module and override the functions I want to manipulate. I will probably run tests in separate processes if it becomes an issue.
In the arrange part of my tests:
// mock out database saves
var db = require("../../schema");
db.Model1.prototype.save = function(callback) {
console.log("in the mock");
callback();
};
db.Model2.prototype.save = function(callback) {
console.log("in the mock");
callback("mock staged an error for testing purposes");
};
I solved this by structuring my code a little. I'm keeping all my mongoose-related stuff in separate classes with APIs like "save", "find", "delete" and no other class does direct access to the database. Then I simply mock those in tests that rely on data.
I did something similar with the actual objects that are returned. For every model I have in mongoose, I have a corresponding class that wraps it and provides access-methods to fields. Those are also easily mocked.
Also worth mentioning:
mockgoose - In-memory DB that mocks Mongoose, for testing purposes.
monckoose - Similar, but takes a different approach (Implements a fake driver). Monckoose seems to be unpublished as of March 2015.