The name parameter to createSpyObj should be optional

328 views
Skip to first unread message

Steven Broshar

unread,
Apr 17, 2014, 6:31:06 PM4/17/14
to jasmi...@googlegroups.com
I suggest that the first/name parameter to createSpyObj should be optional -- omittable for the following reasons:

1. Potentially confusing

As far as I can tell, the name value is only used when a matcher formats an error message.  It's nice to see the name of a the object in the message.  For example: 

var foo = createSpyObj('foo', ['doIt']);

For which Jasmine formats an error like this:
 
Expected spy foo.doIt to have been called.

But, if I pass a confusing name to createSpyObj, like this:

var foo = createSpyObj('bar', ['doIt']);

Jasmine formats this:

Expected spy bar.doIt to have been called.

True, I did name it 'bar' in the call to createSpyObj, but the object variable name is 'foo'. My fault, but confusing.  

2. Consistency with spyOn

Consider what you get with spyOn.  No object name is used in the error message since none is setup.  For example:

spyOn(foo, 'doIt');

for which Jasmine formats this:

Expected spy doIt to have been called.

I prefer less information vs. potentially confusing information. IOW, no object/spy name.  

3. Consistency with createSpy

Also consider that you can omit the name parameter to createSpy in which case an error message uses 'unknown' for the spy name.  That seems reasonable to me.  If the test has just one spy, then no name is fine.  If there there is more than one spy, then the test author might want to include names in each so that the resulting error messages indicate which spy was involved in the failure.  Along these lines, I think the name parameter should be optional for createSpyObj as it is for createSpy.

Conclusion

I can pass blank, null or undefined for the createSpyObj name parameter, but I'd rather not include a first parameter like this:

var foo = createSpyObj([...]);

But, that causes a runtime error.  As is possible in javascript functions, createSpyObj should support optional parameters by testing the type of the parameters -- treating the first parameter as the function names if it's an array.

I am using 1.3.  If this is implemented in 2.0, then cool ... and never mind.

Reply all
Reply to author
Forward
0 new messages