Serial port mock-up

[DavidLibault]

I am trying to make a mock-up to test code using the serialport crate.

From the tester point of view, the mock-up once initialized, is configured for what each mock-up function (available_ports, open, read and write) returns when it is called. The mock-up will also store the calls and answers of each function, so that the tester code can check which functions are called, in order. This rudimentary tool would be enough to verify code behavior in any situation, and also validate serial protocol implementation.

Because available_ports and new are free floating functions, a global variable is needed to store the responses of this function. Here is how it goes :

use std::collections::VecDeque;
use std::sync::RwLock;

static SERIALPORT_MOCKUP: Lazy<RwLock<SerialPortMockup>> = Lazy::new(|| RwLock::new(SerialPortMockup::new()));

struct SerialPortMockup {
    trace: VecDeque<String>,
    available_ports: VecDeque<Result<Vec<SerialPortInfo>>>,
    open_response: VecDeque<bool>,
    write_response: VecDeque<io::Result<usize>>,
    read_response: VecDeque<(String, io::Result<usize>)>,
}

pub fn mockup_append_available_ports(ports: Result<Vec<SerialPortInfo>>) {
    let serialport_mockup = &mut SERIALPORT_MOCKUP.write().unwrap();

    serialport_mockup.available_ports.push_back(ports);
}

pub fn available_ports() -> Result<Vec<SerialPortInfo>> {
    let serialport_mockup = &mut SERIALPORT_MOCKUP.write().unwrap();
    let mut trace_string = String::from("available_ports|");

    if let Some(returned_available_ports) = serialport_mockup.available_ports.pop_front() {

        // etc...

    }
}

It works, but has many problems :

1 - The open answer can not contain the SerialPort trait because it doesn't implement sync. Maybe there is a solution with a rust trick.

2 - This doesn't work in multi threaded test (because the global is shared among all threads). There is a crate to handle this issue named "serial_test". Every test using the serial mockup needs to look like this :

#[test]
#[serial]
fn test_my_nice_test() {
// etc...
}

It works, but the tests can't be run in parallel anymore...

3 - All the structures, traits, errors etc.. from serialport need to be rewritten, most of them without a change, and the tested code needs to selectively use the mock-up or the real thing :

#[cfg(test)]
use crate::serialport_mockup::tests as serialport;

#[cfg(not(test))]
use serialport;

There must be a better solution...

Is it possible to make such mock-up without requiring a global variable ?
Is it possible to have the mock-up integrated in the module so that when it sees #[cfg(test)] it doesn't implement neither a Posix nor a Windows version but a mock-up version, that with nice rust tricks could be configured with sequential predetermined responses ?

Best regards,

David.

[sirhcel]

Mocking the entire serialport crate indeed sounds like a mighty thing. What test cases do you have in mind?

In case that they are mostly about the actual communication, just mocking using the Read and Write traits might already do the trick and provide a Pareto-style solution.

[DavidLibault]

IMHO any decent piece of code that uses a serial port do communicate with a serial device will have to call available_ports(), new() and open() in a non obvious way. For instance, devices tend to be physically disconnected by the user or other, so recovering by closing the non working port, checking if the port is available and, if it is the case open it again is (IMHO again) a must have. For example, the Arduino software doesn't need to be restarted in case your serial device is disconnected/reconnected, or reset for one reason or another. It also enumerates the available ports periodically. So, you can not decorrelate "actual" communication with communication "establishment" in the user software because "actual" communication might have to be reestablished.

So the full serial port API needs to be "mockable" for TDD of this kind of code.

Different users will mock different parts of the API as needed by the use they make of the API.

For example, having a single class (or trait) (like the SerialPortBuilder maybe) that would handle port enumeration, opening, read and write would be easier to inject data and code into without using a global static structure that raises many issues in Rust, and also disables parallel testing.

Ideally the mock would be a serial port kind other than Posix or Windows that would be made available to the user when #[cfg(test] with an additional API for injecting test scenarios...

But that is not the way the serialport-rs API has been designed. Maybe there is rust a way to do this with the serialport-rs API as it is (my rust is rustic)... Any clue ? IMHO any API should be "mockable" without having to use any global variable.