Add tests for String#padStart and String#padEnd

[ljharb]

(tc39/proposal-string-pad-start-end#23)

[jugglinmike]

Looking good, @ljharb! The tests look valid, I just have a few ideas for
extending coverage (and one request for formatting).

The ? shorthand is really convenient, but it tends to hide branches in the
algorithm. As written, these tests only cover one of the case where an internal
operation produces an abrupt completion. This could be done by asserting a
TypeError when a Symbol is specified for the this value, and the second
argument (separate tests, of course). Call me old fashioned, but I still prefer
an ordinary object whose toString/valueOf method throws a
Test262Error--expressing the intention in that way will make the tests portable
to shimmed ES5 environments.

I like the "observable operations" tests! If you want to get really fancy (and
who doesn't want to get fancy?), you could configure these to return ordinary
objects for the "preferred" operation--that would let you observe the "hint"
behavior of ToPrimitive.

The proposal says "If fillString is undefined, [...]", and in cases like
this, I like to explicitly test other falsey values to make sure that there is
no ToBoolean funny business going on.

The tests that have multi-line descriptions should use > rather than | as
a block delimiter because newlines are not significant. (This is a distinction
I personally discovered only recently, so many of my old commits are incorrect
in this regard).

[ljharb]

@jugglinmike I'll add separate tests that throw on the ToString and ToLength branches (which the existing observable ops tests ensure are properly called). I'll also add more non-string + falsy fillString values to cover what you've indicated, and fix the multiline descriptions.

How could I observe the "hint" behavior of toPrimitive? Or do you mean, just the nested toString/valueOf call? That seems like it could recurse forever - at which point would I stop?

[jugglinmike]

How could I observe the "hint" behavior of toPrimitive? Or do you mean, just
the nested toString/valueOf call? That seems like it could recurse forever -
at which point would I stop?

Sorry, that was a bit unclear. Here's the text I had in mind:

[...]
3. If hint is "string", then
   a. Let methodNames be « "toString", "valueOf" ».
4. Else,
   a. Let methodNames be « "valueOf", "toString" ».
5. For each name in methodNames in List order, do
[...]

By defining the toString methods to return a non-primitive value, you'll be
able to observe that valueOf is called following toString in such cases.

-var receiver = createPrimitiveObserver('receiver', 'abc');
+var receiver = createPrimitiveObserver('receiver', {}, 'abc');

-var fillString = createPrimitiveObserver('fillString', 'def');
+var fillString = createPrimitiveObserver('fillString', {}, 'def');

[ljharb]

ah, i see. ok cool, i'll make the changes today

[ljharb]

Updated!

[leobalter]

I believe valueOf:receive happens here as the result of toString:receive is an Object and the the valueOf will return undefined.

[ljharb]

understood and fixed, thanks!

[leobalter]

-var result = String.prototype.padEnd.call(receiver, fillString, maxLength);
+var result = String.prototype.padEnd.call(receiver, maxLength, fillString);

edit: s/padStart/padEnd

[leobalter]

ops (this is padEnd, not padStart, but the same argument order applies)

[leobalter]

LGTM

[leobalter]

Squashed and merged at c95e673, thanks!

[ljharb]

Thank you! :-D