Inconsistent newlines in %D replacement using spy.printf

[hexpunk]

• Sinon version: 4.4.2
• Environment: Ubuntu 16.04, Node v8.9.4, npm 5.7.1
• Other libraries you are using: sinon-chai 2.14.0

What did you expect to happen?
I expected the %D replacement for spy.printf to have the same newline behavior regardless of the number of calls to the spy.

What actually happens
When there's only one call to a spy and I use the %D replacement with spy.printf, a newline is appended to the start of the replacement thanks to this statement which is always executed. However, when multiple calls have been made to the spy, a newline is not placed at the beginning of the replacement because of this conditional which only adds newlines before the "Call n:" label after the first iteration of the loop.

How to reproduce

const Sinon = require('sinon');
const spy = Sinon.spy();
spy(1, 2, 3);
console.log(spy.printf('%D'));  // => "\n1\n2\n3"
spy(4, 5, 6);
console.log(spy.printf('%D'));  // => "Call 1:\n1\n2\n3\nCall 2:\n4\n5\n6"

I this an oversight in formatting or is this an intentional decision? There don't seem to be any explicit unit tests for %D with the rest of the printf tests, but altering how %D works causes tests like the assert.alwaysCalledWithMatch exception message test to fail.

[mroderick]

Thank you for your accurate bug report.

I am sure it's an oversight that the formatting is inconsistent, and it's certainly an oversight that there are no unit tests for %D.

Would you like to contribute another pull request to amend that?

[hexpunk]

I'd love to make a PR to fix this. But, which is the preferred version? With a starting newline or without?

[mroderick]

I don't have strong opinions about this, and welcome discussion if anyone has arguments for either solution.

I'd prefer to always start with a newline, as that's the behaviour for the single call. I assume the single call is the more common usage, so people might have built integrations (like sinon-chai), that expect strings to start with a newline.

[hexpunk]

I concur with your preference. I'll make a PR that makes the multiple call format match the single call format.