I googled the name of those pins and found a file from@PaulStoffregen :
https://github.com/PaulStoffregen/cores/blob/master/teensy3/pins_arduino.h

Is there a larger effort in defining pins that we need to make here? (I won't delay merging this, I'll just open some issues)

Teensy appears to be aArduino compatible ARM Coretex board with 34 I/O pins. So most proper Arduino hardware targets will have less, but I do not feel that there is any problem in overcommitting on providing possible non-existing pin definitions in the test environment. I will add and rebase the branch.

One question though. The pins have different numerical values depending on which hardware target, and some of them are conflicting, e.g.A20 is either 31 or 39 in thepins_arduino.h linked above.
And this is also the case for other pin definitions like

#definePIN_WIRE_SDA         (2)

in~/.arduino15/packages/arduino/hardware/avr/1.6.209/variants/leonardo/pins_arduino.h vs

#definePIN_WIRE_SDA        (18)

in~/.arduino15/packages/arduino/hardware/avr/1.6.209/variants/standard/pins_arduino.h

Do we need to keep a 1-to-1 consistency with all hardware targets? That will be a lot of work, or could I just create an enum with consecutive values (possibly starting on a non-compatible value like 100 just to avoid the situation that some of the pin definition are the same as the real hardware while some are not, and at least be consistent in that none are)).

It sounds like you understand my hesitation here, and I think you're asking the right questions.

Do we need to keep a 1-to-1 consistency with all hardware targets?

No. We just need to make sure that the mocks will work if you stay consistent (i.e. if within the library we refer toA20 and within the unittest we do something likeassertEqual(A20, myLib->somePin), it should always work, and not give a31 =/= 39 assertion error).

I do not feel that there is any problem in overcommitting on providing possible non-existing pin definitions in the test environment

It depends. One of the features offered by this library is the ability to unittest across Arduino hardware platforms, so I need to be somewhat careful that the test environments are accurate. (E.g. a library would break if it was doing#ifdef A20 to determine available hardware features.) I doubt that people are usingA20 in particular for their macros, so that's probably fine. But that's how I'm approaching this.

The sort of pattern I'm trying to support is this one:https://github.com/adafruit/Adafruit-WS2801-Library/blob/master/Adafruit_WS2801.h#L59