Can I hide/remove the UI from Karma result? - unit-testing

I am using angular 6.1.6 and really new to Karma. When I run ng test,
the result shows some elements (please see screenshot here). Can I hide them/remove from my testing result?
Thank you.

I got another answer.
Putting this in the beforeEach function works well
fixture.debugElement.nativeElement.style.visibility = "hidden";
and it would hide the flashing component when testing.

It looks like your test is adding things directly to the dom, which is non-standard (though there are some instances where this is a good idea). In general, your tests should not attach any dom to the document object (eg- by calling document.querySelector('#foo').appendChild(...). If you create dom elements, you should avoid attaching them to the document.
If you do attach dom elements to the document, the simplest way to remove them is in an afterEach block in your describe spec, like this:
afterEach(() => document.querySelector('#my-element').remove());

Related

mapbox-gl - how to instantiate a Map for a simple test

I'd like to start by asking Mapbox - please - to put documentation on their site that explains how to set up and start doing a simple test. There are many tests in their code on Github, but after days of reading and attempting to test I have failed to understand how they work.
I have a very simple method that:
updates some geoJson with some new coordinates and a new heading (rotation) for a marker.
uses setSource to set the changed Json to the Map
I would like to run my little method in a test and then check that the new coordinates have arrived in the Map.
Should be a piece of cake!
Now a Map needs a browser or similar. Yes, there's jsdom, which is almost certainly what is needed, but I have not discovered how you give the dom to the Map.
If I try to instantiate either window, which I found in mapbox-js utils, or Map, I get
ReferenceError: self is not defined. - 'self' appears to be the window object.
I use mocha, with babel 7, for what it's worth, but I think that all I need is to solve the mystery of setting up a Map instance so that I can then interrogate it.
Any help would be gratefully received.

Lazy Loaded Ember Application

I am typically searching for answers here but I finlly gotten to the point where I can't find a good answer.
I am looking to build an ember app which only initially loads in the things that it needs just to start and open the main route. All other controllers, views, templates, etc. Would be loaded lazily when a specific route gets triggered.
I have found a good example of how to accomplIsh this here:
http://madhatted.com/2013/6/29/lazy-loading-with-ember
My main question is to determine what build tools out there support this theory of lazy loading application code? So far, I've seen that Brunch, Yeoman, and Ember App Kit seemed to minify and concatenate all the scripts and templates. I am very happy with minification but need those files separate. I have thought about just putting this code into the app/assets location so that it gets copied over without concat but it does not get minified.
Does anyone have a solution? Thanks!
You can do this with brunch by adding the following to your brunch config
files: {
javascripts: {
joinTo: {
'javascripts/app.js': /^app(\/|\\)(?!admin)/, // concat everything in app, except /app/admin
'javascripts/vendor.js': /^vendor/,
'javascripts/admin.js': /^app(\/|\\)admin/ // concat only /app/admin
}
}
}
Grunt (used in yeoman and ember app kit) is ridiculously flexible, so I'm sure you can set up the same thing there by diving into Gruntfile.js
The question was: "I am looking to build an ember app which only initially loads in the things that it needs just to start and open the main route. All other controllers, views, templates, etc. Would be loaded lazily when a specific route gets triggered.".
Ember expects to have anything it needs right there when the page gets loaded. I wouldn't be wrong, but lazy loading of routes doesn't seem to be a feature of Ember. Ember CLI is the same. It uses bundling and minification to reduce the overload. But everything should be there to make it work.
Instead, people like me would like to load things only when they are required.
When you try to implement lazy loading in Ember, everything should be represented by a module (file.js): a route, a module; a controller, a module; and so on.
You should follow a schema (like POD), to which apply a mechanism to find things where they are supposed to be.
Every module should know its dependencies. But some of them are very frequent (route, controller, template).
You should use a module loader for the browser. It can be requirejs or whatever you like. But ES6 is at the door. Let's think about that.
Many people use beforeModel hook to achieve a result. I did it, and it works, if you don't use link-to component. Otherwise everything crashes. Why? Because of href computed property. When a link-to has been inserted, an href is calculated for it. Because of that, Ember looks for the route where the link points to. If the route doesn't exist, one is created from route:basic.
A solution could be the preloading of all the routes represented by all link-tos inserted in the page. Too much expensive!
An integration to this answer can be found at Lazy loading route definitions in Ember.js
For an initial solution to lazy loading of routes organized in POD, have a look at https://github.com/ricottatosta/ember-wiz. It is an ES6 based approach, which relay on SystemJS as module loader.

good examples of testing ember with rest adapter in quint or mocha

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

Unit Testing basic Controllers

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.

Play framework testing controller method

I have a controller method that fetches data to render(fetched data) a HTML view of the same. I wanted to write a test to ensure the jpa model is queried correctly. However I am not finding a way to intercept what is being passed into render().
Can someone please let me know if there is a way to get what is passed into render from a test case. If not should I move this code/line into a different class that I can test easily.
Thanks
I know it's not exactly what you want but you could just write some selenium tests that will confirm whether the controller is rendering the correct data in the template. (see: http://www.playframework.org/documentation/1.2.4/guide10#selenium)
Also writing a Functional Test may help (see: http://www.playframework.org/documentation/1.2.4/guide10#controller)
Could you see if the Play Response object i.e. the out contains your expected value?