Shortcut for new stub returning args

[davidbarton]

When I use one line to create new function stub and return some arguments, it gets messy really fast. So instead of writing

const t1 = td.when(td.function()(options, limit)).thenReturn('first', 'last')

It would be possible to write something like this

const t1 = td.whenFn(options, limit).thenReturn('first', 'last')

[searls]

I don't really understand this proposed API. How would you specify args and matchers in the stubbing?

[davidbarton]

Arguments and matches are put directly to new shortcut fn. In this case options, limit are arguments.

• no argument stub const t1 = td.whenFn().thenReturn('first', 'last')
• argument stub const t1 = td.whenFn(options, limit).thenReturn('first', 'last')
• matcher stub const t1 = td.whenFn(td.matchers.isA(Number)).thenReturn('first', 'last')

[searls]

I don't understand, how would an implementation of whenFn know the difference between when it's being passed an argument and when it's being passed an options object?

[searls]

(btw, limit shouldn't be necessary, because times is an existing options entry) (Doc)

[davidbarton]

Ohh sorry for that options and limit are just confusing variable names. They are meant to be any arguments. I did copy them from my test.

[searls]

Hmm, ok. So that yields the next question: how do people set options on the stubbing?

[davidbarton]

I did not think of them, would probably let you use full format when you need options and have shortcut only without them.

[searls]

Ok, I understand the proposal now.

I'm pretty conservative in keeping the surface area of the test double API distinct. Since it's an opinionated library, I generally only want there to be one way to do something unless there's a tremendous advantage to providing a shortcut. Because the variability in stubbing & verifying is, frankly, enormous, any synonyms or shortcuts risk confusing people even more as they try to learn an already confusing API.

I am especially reticent to add new top-level methods to the td object, since it increases the cost of someone exploring the API top-down to understand what the library does.

I don't think this proposed API adds enough benefit to outweigh those documentation and confusion risks. When I look at Sinon, with its several ways to create the same stubbing, the numerous bugs they encounter when an option works in one stubbing style but not another is a real problem that I am careful to avoid here.

I'd recommend defining this helper yourself with something like:

whenFn = function (args...) {
  return function (stubbings...) {
    return td.when(td.func()(...args)).thenReturn(...stubbings)
  }
}

[davidbarton]

Ok, thanks for consideration. I will probably do own helper as you suggested since it makes my code lot more readable.