Let's say I have this directive:
.directive 'panelcreator', ->
(scope, element)->
element.bind 'mouseenter', ->
element.addClass 'alert alert-danger'
To keep this a unit spec, I want to stub out element.addClass, right? So how do I go about doing this?
My attempt:
describe 'panelcreator', ->
describe 'something', ->
beforeEach ->
spyOn(element, 'addClass')
element.trigger('mouseenter')
it 'shoud create a panel', ->
expect(element.addClass).toHaveBeenCalledWith 'alert alert-danger'
Gives me:
Error: Expected a spy, but got Function.
How do I go about analysing a variable such as element in future so I can find out the method chain I need to pass SpyOn?
If using jQuery, addClass will be on the jQuery object:
spyOn($.fn, 'addClass');
If not, it will be on jqLite (angular.element) object:
spyOn(angular.element, 'addClass');
You don't need to stub addClass to "keep it a unit spec", there's nothing wrong with using a real Element.
Stubbing a method is good when testing use of some discrete interface with a single point of access. DOM elements, however, are complex data structures with (usually) more than one way to perform a certain action. If you were to test that your function adds an element to an Array, you wouldn't want to stub .push() either (as there are many other ways to add an item). So, when testing DOM interaction, you can just add DOM elements to the list of "utility" stuff you're allowed to use (instead of stubbing).
When testing whether a class is added, just check its presence.
Note that this makes your bounty question invalid. To make it absolutely clear in general terms:
Yes, you could inspect the source code of jqLite (possibly by stepping through addClass call) and find out that you need to observe the real Element, not its angular.element() wrapper. Thus, you could try to stub Element.classList.add().
However, the whole previous paragraph is irrelevant. Stubbing is only appropriate when you need to test use of an entity without the need to provide an implementation and/or rely on it. Both Element and its jqLite wrapper have guaranteed forward-compatible stable functionality and their implementation is implicitly provided, since your code runs in a web browser and uses AngularJS. This makes stubbing either of them counter-productive.
Have you tried
spyOn(element.prototype, 'addClass') ?
and then
expect(element.prototype.addClass).toHaveBeenCalledWith 'alert alert-danger'
Related
I have an angular-application where I put custom html-attributes ("data-testid='saveButton'") for identification on e.g. buttons, inputs etc.
Protractor has no built-in locator for this: the xpath-way does not work as this will always search from the document root (to overcome this limitation I would have to do quite a lot of string-magic to build the xpath-string, so I discarded this variant).
So I wanted to write my own locator, and consulted the official Protractor Documentation.
The documentation leaves me with an important question:
What methods are available on the parent-element-object? In their example they use using.querySelectorAll('button'); but how do they know they can use this?
I searched for 'querySelectorAll' in the protractor-documentation to see if it is maybe a method of ElementFinder or WebElement, but I didn't find it.
Also I found no way to debug the locator (only stop the protractor-test by browser.pause()), so I can't look at runtime to see what I can do with the given parent-element.
So does anybody know how I can get information about what methods the parent-element has?
The parent-element, which is essentially the context of the selector is a DOM element that gets handled by the browser - it can use whatever DOM function there is, in this case Element.querySelectorAll. As the addLocator's example says about the function you pass to it:
This function will be serialized as a string and will execute in the browser.
Also, keep in mind that there is a way to provide context to the xpath selectors thus avoiding the search from root:
var context = element(by.css('.some-parent-element-class'));
var divDirectDescendants = context.element(by.xpath('div'));
var divAllDescendants = context.element(by.xpath('.//div'));
With CSS these would be:
var divDirectDescendants = element(by.css('.some-parent-element-class > div'));
var divAllDescendants = element(by.css('.some-parent-element-class div'));
Also, there's a way to achieve what you want with a CSS selector (which is what querySelectorAll is, after all):
var everyElementWithMyAttr = element.all(by.css('[data-testid="saveButton"]'));
According to the How do I assert an element is focused? thread, you can check if an element is focused by switching to an activeElement() and assert this is the same element you've expected to have the focus:
expect(page.element.getAttribute('id')).toEqual(browser.driver.switchTo().activeElement().getAttribute('id'));
In my case, the currently focused element does not have an id attribute.
What should I do instead of checking an id?
Bonus question: Also, as you can see from my tries to solve it, it looks like I cannot expect/assert an element (or web element) as a complete object. Why?
I've tried:
expect(page.element).toEqual(browser.driver.switchTo().activeElement());
But is is failing with an error I cannot even understand - there is a huge traceback (it is about 10 minutes to scroll in the console), but no user-friendly error inside.
I've also tried to use getWebElement():
expect(page.element.getWebElement()).toEqual(browser.driver.switchTo().activeElement());
But this resulted into the following error:
Error: expect called with WebElement argument, expected a Promise. Did
you mean to use .getText()?
Using the latest protractor development version.
In my answer I'm going to assume activeElem and pageElem are both protractor element finders, and are pointing to the same web element.
First to answer your question about why
expect(activeElem).toEqual(pageElem);
Gets into an infinite loop, it's because protractor patched jasmine's expect to resolve the promise before asserting, so that things like expect(activeElem.getText()).toEqual('text'); works without having to do
activeElem.getText().then(function(text) {
expect(text).toEqual('text');
})
You could say, why not just resolve the promise once? But then there are nested promises.
So now you might be thinking this is an issue, but it really isn't because you would never compare two elementFinders in a real use case. Jasmine's toEqual does a reference check, and not a deep compare, so expect(activeElem).toEqual(pageElem), is just the same as a simple reference comparison: (activeElem === pageElem).toToTruthy(), and there's really no point doing that. (Note element(by.css('html')) === element(by.css('html')) is false because it's not the same reference.)
So, to answer the real question for this thread: how to see if two elementFinders have the same underlying webelements:
expect(activeElem.getId()).toEqual(pageElem.getId());
It's weird that it's expecting a promise only and could not handle a webdriver element... I had the same HUGE stacktrace as you.
Anyway, would you accept this kind of solution: send a "dumb" promise with a nice comment to justify why you had to do that. It's more a workaround than a semantic solution I admit.
expect(page.element.getInnerHtml())
.toEqual(browser.driver.switchTo().activeElement().getInnerHtml());
It's working for me ;)
EDIT: Bonus answer
The reason you can't call expect with a WebElement comes from the Webdriver Control Flow Principle (I'm sure you already know about) and this line in jasminewd, the adapter for jasmine to Webdriver developped and used by Protractor ;)
For the future readers, I've created a custom matcher to assert if an element is active/focused:
beforeEach(function() {
jasmine.addMatchers({
toBeActive: function() {
return {
compare: function(elm) {
return {
pass: elm.getId().then(function (activeElementID) {
return browser.driver.switchTo().activeElement().getId().then(function (currentElementID) {
return jasmine.matchersUtil.equals(currentElementID, activeElementID);
});
})
};
}
};
}
});
});
Usage:
expect(element(by.css("#myid")).toBeActive();
What about using CSS selectors and :focus
expect(element.all(by.css('#myid:focus')).count()).toBe(1);
I solved it by using protractor's:
ElementFinder.prototype.equals
const activeElement = await browser.driver.switchTo().activeElement();
const potentialyFocusedElement = await component.$('your-locator');
const isFocused = await potentialyFocusedElement.equals(activeElement);
I am not sure how exactly equals work, if it does a deep compare, or it somehow compares instances. But it works.
Note that you can not call activeElement.equals(...) since it is not an ElementFinder, it is a WebElement.
You need to come up with a way to tell Protractor/webdriver how to find your element on the page. Protractor uses JavaScript to find elements, so any of the tools available for inspecting the DOM are available. Protractor and webdriver wrap these APIs in the various by flavors:
http://angular.github.io/protractor/#/api?view=ProtractorBy
In addition to the basic flavors, Protractor adds Angular-aware flavors (so you can search by Angular binding, etc).
If your element does not have any distinguishing characteristics, then it might be worth adding something to make it easier to test. Or, (though this is often frowned upon because its so fragile), you can use an xpath. See https://github.com/angular/protractor/blob/master/docs/locators.md
You can simply check the text (or anything else) of the element:
var currentElement = browser.switchTo().activeElement();
expect(currentElement.getText()).toEqual(page.element.getText());
I've set up a project where I've extended a Backbone.Marionette.Layout that contains two different regions. This layout can be used as a component throughout the application. In particular, the regions are set up like the following.
regions : {
masterRegion : { selector: '[data-region=master]' },
slaveRegion: { selector: '[data-region=slave]' }
},
In particular, I'm using a data-region selector to inject the view I'm interested in.
When such a layout is used in a tree structure views are duplicated since getEl function adresses the wrong region to inject the view. Obviously it's my fault and within Marionette (v1.1.0) doc the following is written.
override the getEl function if we have a parentEl this must be
overridden to ensure the selector is found on the first use of the
region. if we try to assign the region's el to parentEl.find(selector)
in the object literal to build the region, the element will not be
guaranteed to be in the DOM already, and will cause problems
where getEl is defined as
getEl: function(selector){
return Marionette.$(selector);
}
So, my question is the following. What does this mean? How can I override this method? Where is the correct to perform such an override?
Hope it's clear.
Here's my understanding of this:
the points below apply to the case where the layout is contained within another element ("if we have a parentEl")
the first time you use a region, Marionette needs to select the proper DOM element to populate, according to the selector string ("ensure the selector is found on the first use of the region")
you can't simply look for the selector in the parentEl ("if we try to assign the region's el to parentEl.find(selector) in the object literal"), because the DOM element we want isn't necessarily in the DOM yet ("the element will not be guaranteed to be in the DOM already")
In other words, the first time you use a region (e.g. with a call to the show method), Marionette needs to build a region instance and associate it with the correct DOM element (specified by the selectorattribute).
However, before Marionette can look for the DOM element within the containing parent element, it must ensure that all required DOM elements (most importantly the one we're looking for) have loaded.
Does that make more sense to you?
Edit based on flexaddicted's comment.
Could you suggest me a the correct way to achieve this? Is there any
manner to override the method below?
I don't think you need to override this method. The comment indicates why the DOM element is fetched that way instead of by direct assignment when the region is built, but it should still work properly with a tree structure (since parents can still be determined properly).
I think the problem might be with your region selector: as it is "generic", it can potentially match multiple elements (as opposed to selecting with an id attribute that should match only 1 element), and could be matching a DOM element you're not expecting such as a child view. (This of course depends on when Marionette looks at the DOM to fetch the selector.)
Also, I'd consider using a composite view for your tree structure needs if possible. See http://davidsulc.com/blog/2013/02/03/tutorial-nested-views-using-backbone-marionettes-compositeview/ and http://lostechies.com/derickbailey/2012/04/05/composite-views-tree-structures-tables-and-more/
I am trying to bind a property of an object to a property that's bound in an ArrayController. I want all of this to occur after the object has already been created and added to the ArrayController.
Here is a fiddle with a simplified example of what I'm trying to achieve.
I am wondering if I'm having problems with scope - I've already tried to bind to the global path (i.e. 'App.objectTwoController.objectOne.param3') to set the binding to. I've also tried to bind directly to the objectOneController (which is not what I want to do, but tried it just to see if it worked) and that still didn't work.
Any ideas on what I'm doing incorrectly? Thanks in advance for taking the time to look at this post.
So in the example below (I simplified it a little bit, but same principles apply)... The method below ends up looking for "objectOne" on "objectTwo" instead of on the "objectTwoController".
var objectTwoController: Em.Object.create({
objectOneBinding: 'App.objectOne',
objectTwoBinding: 'App.objectTwo',
_onSomething: function() {
var objectTwo = this.get('objectTwo');
objectTwo.bind('param2', Em.Binding.from('objectOne.param3'));
}.observes('something')
});
The problem is that you can't bind between two none relative objects. If you look in the "connect" method in ember you will see that it only takes one reference object (this) in which to observe both paths (this is true for 9.8.1 from your example and the ember-pre-1.0 release).
You have few options (that I can think of at least).
First: You can tell the objects about each other and in turn the relative paths will start working. This will actually give "objectTwo" an object to reference when binding paths.
....
objectTwo.set('objectOne', this.get('objectOne');
....
Second: You could add your own observer/computed property that will just keep the two in sync (but it is a little more verbose). You might be able to pull off something really slick but it maybe difficult. Even go so far as writing your own binding (like Transforms) to allow you to bind two non-related objects as long as you have paths to both.
_param3: function(){
this.setPath('objectTwo.param2', this.getPath('objectOne.param3');
}.observes('objectOne.param3')
You can make these dynamically and not need to pre-define them...
Third: Simply make them global paths; "App.objectOneController.content.param3" should work as your binding "_from" path (but not sure how much this helps you in your real application, because with larger applications I personally don't like everything global).
EDIT: When setting the full paths. Make sure you wait until end of the current cycle before fetching the value because bindings don't always update until everything is flushed. Meaning, your alert message needs to be wrapped in Ember.run.next or you will not see the change.
For the moment, we're loading site-wide event-listeners from a single common.js file for a Rails project. We're aware of (most of) the trade-offs involved there, and are just trying to mitigate them. Once our basic architecture takes hold, we may move them off to separate files by controller or by view.
For the moment, the quick question is how we can activate them only when necessary, which begs the mangled, pseudo-zen question:
if an event-listener is declared in a forest when nobody is around to hear it, does it still make a sound?
In other words, if one declares a basic listener (i.e., nothing persistent like .live() or .delegate()) in the JavaScript for a given page, and the target element is not actually present on that given page, does anything really happen, other than the few cycles devoted to evaluating it and checking the DOM for the element? Is it active in memory, looking for that element? Something else? It never seems to throw an error, which is interesting, given that in other contexts a call like that would generate a null/nil/invalid type of error.
For instance:
$(document).ready(function () {
$('#element').bind('blur keyup', function);
}
Assume that #element isn't present. Does anything really happen? Moreover is it any better to wrap it in a pre-filter like:
$(document).ready(function () {
if ($('#element')) {
$('#element').bind('blur keyup', function);
}
Or, are the .js interpreters in the browsers smart enough to simply ignore a basic listener declared on an element that's not present at $(document).ready? Should we just declare the initial, simple form above, and leave it at that, or will checking for the element first somehow save us a few precious resources and/or avoid some hidden errors we're not seeing? Or is there another angle I'm missing?
JQuery was designed to work with 0+ selected elements.
If no elements were selected, nothing will happen.
Note that you will never get null when using jQuery selector. For example:
$('#IDontExist') // != null
$('#IDontExist').length === 0 // true (it's ajQuery object with
// zero selected elements).
The docs says:
If no elements match the provided selector, the new jQuery object is "empty"; that is, it contains no elements and has .length property of 0.
$('#element') if results into empty set then jQuery will not do anything.
Since jQuery always returns an object we can can call the methods on an empty set also but internally it will do the checking before applying it's logic.
Even if you want to check if the element exists before attaching the event handler you can use length property of jQuery object.
if ($('#element').length > 0) {
$('#element').bind('blur keyup', function);
}