I thought that it's a duplicate, but there's clear no issue about this. We'll likely need an API change. Probably Default impl or cfg(test) impl will work.

You can also construct specific bits, like logical/physical key, which should be more or less sufficient for testing.

I think either of those options would work. I was also wondering if the field value could be an option.

Agreed, I can get quite a lot of mileage from the components, but it would be nice to be able to pass the whole event to a handler method.

I assume any API changes now would be released with the trait API, or later?

Similarly, for Modifiers, it's not possible for me to create unit tests where my function received a Modifiers from the event because I cannot instantiate the object with which left/right modifiers are pressed or unknown. I can use ModifiersState.into() to create an instance of Modifiers, but that's about it. It would be helpful to expose a way to create a "real" instance of this object for testing purposes.

I suppose this holds for all of the data structures that can be received in events.

There are of course other approaches, such as creating my own object and taking the necessary values from Modifiers but it would be nice to avoid this extra layer of indirection.

I can use ModifiersState.into() to create an instance of Modifiers, but that's about it. It would be helpful to expose a way to create a "real" instance of this object for testing purposes.

into is a real instance, you can also use Default. The Right/Light is platform specific and shouldn't be relied upon unless you really know what you're doing and why you're doing that. The type that it's Undefined should also suggest that.

Does that mean the physical/logical key + location should be used for modifiers instead? If that's the case, when should Modifiers be used?

If you want to detect a particular button press, use logical_key, if you want to detect general state change for bindings, use the Modifiers event.

Modifiers could be changed without any button press at all.

We've discussed it a bit with @madsmtm and I think the current way forward would be to try to make the KeyEventExtra parts pub or provide a way to build it without the extra.

The issue with making it pub is that the trait is not present for all backends and some backends have this type empty, so it could make tests a bit harder to write(will require cfg), but given that the cfg stuff is already present in the user code if they use extra it's likely fine.