I am writing a driver for an IMU sensor using test driven development approach. Communication protocol of choice is SPI. Using CubeMX and STM32F415 processor, SPI interface is implemented in stm32f4xx_hal_spi.h file, which contains many and more function declarations. Note this SPI interface is processor-specific and IMU driver may also be implemented on different platforms so flexibility is also important.
For test driven development needs I have to mock SPI functions I use within driver code. I came up with two possible options:
1) Original SPI header file stm32fxx_hal_spi.h is included directly into driver header. Its entire contents gets mocked, even though only very few functions are acutally used in sensor driver.
- straightforward implementation
- actual SPI driver files have to be copied into sensor driver project
- mocking fat interface
2) Within driver project create spi.h header. Re-declare functions that are used by driver but are originally already declared in stm32fxx_hal_spi.h . Mocking spi.h gives mocks only for functions actually used.
no need to copy processor-specific SPI driver files into sensor driver project
mock only things used
- test driving seems straightforward but am unsure how to integrate with hardware and stm32fxx_hal_spi.h file
It seems to me that second approach does a better job in terms of abstracting spi implementation into a single header file. But as mentioned, I am unsure how to proceed to link this to actual spi driver files during integration of sensor driver into entire project.
Is any of these considered a valid approach? Is there a generally accepted approach for this during driver development?