2

Recently I've been reading into topic of test driven development and decided to give it a go with a sensor driver I need. Sensor uses SPI interface and I will implement this driver on STM32F415 processor with help of CubeMX for project generation. After generating project, I have access to HAL SPI functions such as this:

HAL_StatusTypeDef HAL_SPI_Transmit(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size, uint32_t Timeout)

I would create a header file called 'sensor_hall.h', put this SPI function declaration in it and then generate a mock of this header using CMock.

My questions are, is this a valid approach? Should I introduce more abstraction to this? And how to deal with the first argument, pointer to SPI struct when mocking?

Improve this question
2

1 Answer 1

Reset to default
2

Your instincts are correct and you are proposing a valid approach. There is no need to add more abstraction into the mix here.

Assuming there is also a HAL_SPI_* function to obtain (a pointer to) a spi struct, you can use a mock-specific version of a spi struct that contains useful members for your mocks.

If the spi struct needs to be declared directly by the client code (your sensor driver), then I would just verify in the mocks that consistently the same pointer is passed in.

Improve this answer
5
  • The struct is initialized in client code but contains one vital info (apart from some status stuff): a pointer to the hardware registers of this specific peripheral.
    – jaskij
    Aug 3, 2018 at 17:23
  • Would it be an oversimplification if I were to write my own functions, i.e. SPI_Write(addr, data) and SPI_Read(addr) and mock those functions for test while implementing them using the above mentioned HAL_SPI_* functions for production code?
    – hbrezak
    Aug 7, 2018 at 9:44
  • 1
    @hbrezak: That depends on how much logic you implement in SPI_Write/SPI_Read. If they are simple wrappers around the HAL_SPI_* functions that can be verified to be correct at a glance, then go ahead. If they are more complex, you should write tests for those functions as well and you have to consider if that is worth the effort.
    – Bart van Ingen Schenau
    Aug 7, 2018 at 10:26
  • It seems that this SPI_HandleTypeDef struct is more complex than I thought. It includes multiple nontrivial structs such as SPI_TypeDef and HAL_LockTypeDef. If I think ahead, I predict I will need to test drive a sensor initialization function and will probably want to test if this struct is filled correctly. Any advice on how to proceed?
    – hbrezak
    Aug 9, 2018 at 19:03
  • @hbrezak: For such complex structs that are mandated by external dependencies (which you didn't design/write), I usually defer testing that it is filled correctly until an integration-testing phase where both components need to work together. The chance that you make the same mistake regarding the contents of the struct in both the test and the production code is too high.
    – Bart van Ingen Schenau
    Aug 10, 2018 at 6:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.