A few months ago @Krinkle identified an API problem when passing undefined to the cookie value. Basically in that situation, the return of a function that is supposed to generate a cookie value should not be interpreted as a getter.

Now we have a similar situation with the cookie attributes. The documentation doesn't say that undefined is a valid input for a cookie attribute, so the intent of the code just assumes the value will be truthy and uses && to check for it. The only actual benefit of using logical && operator was to reduce a few bytes gzipped when they were removed in bulk here.

Fortunately, [undefined].join('') returns "" in the operation to persist the cookie, so it doesn't write c=v; path=/undefined for domain: undefined like what happened to the expires: false attribute.

Unfortunately that is not tested.

• This PR test the behavior to ensure that if the code changes, the behavior will always stay the same.
• In other hand I don't know if the test is entirely necessary, because it also define a noop behavior for the undefined value, which might not be wise since it will become implicitly supported and cannot be changed in any future minor version bump.

Example:

var domain = getDomain(); // returns undefined
Cookies.set('name', 'value', {
    domain: domain
    // domain: undefined
});

Is it worth testing this behavior?