use `embedded_hal::digital::ErrorKind` for mocked digital pins

[2bndy5]

I find it weird that eh1::MockError only has an Io variant for an std::io::ErrorKind. Because most embedded rust cannot use std::io in production code, the tested scenario is unlikely to ever occur. IMHO, it would make more sense to allow eh1::digital::Transaction::with_error() to accept embedded_hal::digital::ErrorKind parameter type. This should be especially useful for measuring coverage of an embedded driver lib that wraps embedded_hal::*::ErrorKind into a custom Error type.

Would it be feasible to let eh1::digital::Transaction::with_error() accept embedded_hal::digital::ErrorKind parameter type?

Caution

This would break backward compatibility downstream because MockError is a different type. Adding more variants to the MockError enum wouldn't cover code that (for example)

use embedded_hal::digital::ErrorKind as OutputPinError;

impl From<OutputPinError> for CustomError<OutputPinError> {
    fn from(value: OutputPinError) -> Self {
        CustomError::DigitalOutError(value)
    }
}

[simonsso]

I think the purpose of embedded_hal_mock is to run tests in a rich environment where you do have access to stdlib. The errors from embedded_hal_mock should never reach the embedded code.

[2bndy5]

I think the purpose of embedded_hal_mock is to run tests in a rich environment where you do have access to stdlib. The errors from embedded_hal_mock should never reach the embedded code.

This kind of makes sense if you are testing an application. But when testing a library that wraps embedded_hal errors in a custom error type, it makes more sense (to me) to use embedded_hal errors instead. Otherwise, code coverage is never triggered on the custom error types' conversion (see snippets in OP).