Simple Jasmine test fails with "Expected { } to be { }. "

12,960 views
Skip to first unread message

David Karr

unread,
Oct 4, 2013, 6:11:28 PM10/4/13
to jasmi...@googlegroups.com
Win7x32, Maven, Karma, PhantomJS, Jasmine.

I'm working on a POC of javascript unit tests using the aforementioned stack.  I just installed node along with the various plugins, so my versions are likely the latest.

My first test is exceptionally trivial:
(function() {
    describe("data.daily", function() {
        it("data should be empty", function() {
            var dataDaily    = new Data.Daily();
            dataDaily.initialize(Config.AJAX_DAILY_DATA_BASE_URL, Config.MOCKDATA_AJAX_DAILY_DATA_BASE_URL);
            expect(dataDaily.getData()).toBe({});
        });
    });
})();

This fails with the mystifying message:
    Expected {  } to be {  }.

I've tried changing the "toBe()" argument to something else, like '{"xxx":"yyy"}' and this produces the expected:
    Expected {  } to be { xxx : 'yyy' }.

I don't understand why {} is not equal to {}.

Michael Bielski

unread,
Oct 4, 2013, 6:15:18 PM10/4/13
to jasmi...@googlegroups.com
Try using toEqual({}) instead. It generally works for me.

Davis W. Frank

unread,
Oct 4, 2013, 6:15:17 PM10/4/13
to jasmi...@googlegroups.com
Which version of Jasmine are you using? Where is NodeJS in your system?

You should not need the wrapping function.

What happens on dataDaily.getData()?

--dwf


--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jasmine-js+...@googlegroups.com.
To post to this group, send email to jasmi...@googlegroups.com.
Visit this group at http://groups.google.com/group/jasmine-js.
For more options, visit https://groups.google.com/groups/opt_out.



--
thx,
--dwf

David Karr

unread,
Oct 4, 2013, 6:29:21 PM10/4/13
to jasmi...@googlegroups.com


On Friday, October 4, 2013 3:15:18 PM UTC-7, Michael Bielski wrote:
Try using toEqual({}) instead. It generally works for me.

Ok, I see. toBe() uses === and toEqual() uses ==.  It's curious that I saw the "toBe()" test succeed once or twice, but after that it was failing. Now that I'm using toEqual(), it's working fine.

David Karr

unread,
Oct 4, 2013, 6:32:30 PM10/4/13
to jasmi...@googlegroups.com

The change from "toBe()" to "toEqual()" fixed my problem.


On Friday, October 4, 2013 3:15:17 PM UTC-7, DWF wrote:
Which version of Jasmine are you using? Where is NodeJS in your system?

You should not need the wrapping function.

Acknowledged.  I thought that might be the case.  This code was cloned from a code sample from an angularjs book. That was going to be one of my cleanup steps.  It still works fine without the wrapper.
 

David Karr

unread,
Oct 4, 2013, 7:39:07 PM10/4/13
to jasmi...@googlegroups.com

Note that there is another somewhat mystifying thing happening.  For background, when the application I'm writing tests for is running normally, it submits ajax calls to several different urls on a scheduled basis.  The unit test doesn't (intentionally) do any of that. It just creates one object which initializes some simple properties, then calls the getter for the data object.  However, in addition to the "Expected { } ..." error, I also see several lines like this in the output (somewhat obscured):
WARN [web-server]: 404: /myapp/service/thing/automation/serviceCallResults.json?v=2318
WARN [web-server]: 404: /myapp/service/thing/buyflow/serviceCallResults.json?v=7
WARN [web-server]: 404: /myapp/service/thing/automation/serviceCallResults.json?v=4500

This doesn't cause the test to fail, it's just an oddity.  I have no idea why it is doing this, and I'd like to remove this noise if possible.
These urls correspond to the ajax calls the application would normally make, but without the host prefix.  It makes no sense that executing the unit test would somehow make it try to reach those urls.

Rajan Agaskar

unread,
Oct 8, 2013, 12:31:26 PM10/8/13
to jasmi...@googlegroups.com
To clarify for future readers:

toBe is strict equality, IE, the compared values must be the same reference. One object in javascript is *not* the same as another, different object, even if both of them happen to be 'empty' object. I like to call jasmine's toEqual 'kinda-sorta-equality'. It's == with some extra help to behave as most people would expect. I rarely use toEqual and prefer toBe in most cases. 

Javascript equality is pretty crazy compared to other languages. Simple equality (==) will often coerce types and behave in unexpected ways. I'd highly recommend that jasmine users spend some time familiarizing themselves with how it works because we tend to get a lot of questions about it. Here's a good place to start: http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons

Thanks!

R. 


--

Michael Bielski

unread,
Oct 8, 2013, 12:46:36 PM10/8/13
to jasmi...@googlegroups.com
I do agree that using strict equality (===) is preferable in nearly all of my JS. That SO link is great reading. Like you, I had to resort to toEqual (or ==) to get some of my tests to work, and while it bothers me, it does work and I have to get on with my project. Change what I can, accept what I can't, so to speak. Hopefully you've cleared some things up for people in the future.

Eddie Hedges

unread,
Dec 9, 2013, 12:35:59 PM12/9/13
to jasmi...@googlegroups.com
So are you saying if typeof evaluates both to object and they are both an empty object toBe will fail? I thought '===' compared equality and type? I didn't think they had to be the exact same object...

Ben Loveridge

unread,
Dec 9, 2013, 1:00:44 PM12/9/13
to jasmi...@googlegroups.com
'==' tests equality, '===' tests identity. In primitive objects (ie numbers, strings) there is no difference, but with full objects there is. 

Consider passing an object around between functions. Passing 'var a=5;' the receiver can't modify your object in any war. Conversely if you send 'var o={};' any changes made by the receiver will be made in your original object because they are literally the same instance of an Object. This is the type of identity comparison tested by '==='. 

-- 
Ben Loveridge
Reply all
Reply to author
Forward
0 new messages