Hey @isaacaggrey, Thanks for reporting the bug!

I agree this should be supported. I have a fix for both the array and datatable notations using Symbols. So for example, your dataTable example will look like this:

unroll('should be okay with id being #id', (done, testArgs) => {
    let object = { id: testArgs.id };
    expect(object.id).toEqual(testArgs.id);
    done();
},
`
    where:
    id
    ${Symbol.keyFor(unroll.NULL)}
    ${Symbol.keyFor(unroll.UNDEFINED)}
`
);

and the array notation:

unroll('should be okay with id being #id', (done, testArgs) => {
    let object = { id: testArgs.id };
    expect(object.id).toEqual(testArgs.id);
    done();
},
[
   ['id']
   [null],
   [undefined],
   [Unroll.NULL],
   [Unroll.UNDEFINED],
]

Admittedly, the dataTable example is ugly (though one could argue it's a little messy anyway cos of the need for JSON.stringify), this is because unroll needs to know that the undefined is intentional so a placeholder replacement has to be used as an identifier. And I'd like to keep functional parity between the two notations; I wouldn't want to be able to use null and undefined in array notation but not dataTables.

But I don't think there is an easier way of representing undefined or null` without removing the check (and subsequent thrown error) that the test title has not been expanded properly. The alternative is to get rid of the error checking but I think that's useful for the developer.

Would be interested in your thoughts and preferences as an end user. AFAIK, I'm the main user of the util so would be good to get other users opinion before I push this.

@lawrencec any plans to merge this PR?