Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Nice keyboard flash
I don't use unit tests in embedded, and I won't change that. A lot of embedded code is about external behaviour, not computation. That's why hardware-in-the-loop-tests need to be done, typically with mocking up the whole environment, and then requirement based testing.
And no, TDD doesn't lead anywhere. Test design and test implementation shouldn't be done by the firmware coder at all so that independence is preserved.
Scade6371yI find accepance testing much more useful in firmware development. Nevertheless there are parts in firmware development where unit testing is a great tool. I can also recommend the book posted by OP.
@Fast-Nop I do not disagree regarding hardware in the loop. That is most definitely needed.
In the automotive industry we per the OEMs we have need to follow ASpicd, v model and iso26262... if we don’t unit test we will fail the audits.
Do I believe we have the time to mock the entire system no. But we as the software always are the last to finish our portion because we are then last to receive physical hardware from the Electrical as they have to wait for mechanical group to finish.. and it all trickles down the line.
In the time we wait we know what the requirements are we have an idea of what needs to be done we do have some time to mock up units. Do we always succeed and do it right now because time.. so we compensate by the hardware in the loop tests.
The problem with this is it leaves a lot of room open to forgetting to tests functions for bound and ranges and valid inputs and outputs. This is where unit testing the functions either mocked on host or on target using Cmock or VectorCast or IBM concert I Believe it’s called? I don’t remember.
Anyway TDD.. is it the correct approach ? No we cannot follow it to a T I did not mean that.. but ideas from TDD can be successfully implemented in embedded systems to reduce problems found either at with HIL tests or god forbid things found in the field.
I’ve seen too many times where due to misreading of datasheets of ICs of the system leading to their full values being read by the system and acted upon are not fully covered.
@Fast-Nop Example a light sensor receiving 0 from a light sensor and not covering a situation that low light.. because you assumed light level conditions in the environment could not get that low. Which they truly can’t. But you decide to make a function that does math on the result from the light sensor... that algorithm has division, and thus you end up dividing by 0 .... at first glance when writing the program you don’t see a problem because “the light level can never be that low” so we would never receive that value from the light sensor.....
You do your HIL and no issue becuase you/ testers designed the tests around normal conditions or slightly outside normal conditions maybe some extreme conditions but never do you simulate what happens if you receive a literal 0 from the light sensor? ... all your tests were from the normal and extreme values comming from the sensor.. AND you covered the condition that if no light sensor is present contain works aswell...
What you failed to realize 0 is an actual valid result from the light sensor and is used to tell that there is an internal error with the light sensor, it’s an error but valid result. Thus because the way it was written the person took data from the light sensor did not filtering and divided by zero causing undefined behavior.. a simple unit test would have caught this.
Will it catch everything no.
Is it becuase of programmer error yes.
Is everyone perfect no.. so to aid us.... unit test. It helps ensure all algorithms, functions etc function the way we expect prior to HIL testing and system integration.
Does programmers need to be abstracted from the test to ensure non bias yes, but we can write our own unit tests.. even better pair programming one writes the tests and the other writes the code. And flip flop. We started practicing that about a year ago and we have caught a lot more “stupid” run time errors that are completely independent of hardware and 100% todo with logic.
@QuanticoCEO Well, we mock the entire system, and we don't have schedule problems (ok, we do, but for other reasons) because code implementation and testing implementation are done in parallel by different people.
On the other hand, we do have advanced tooling for static code analysis before the code even gets tested.
And in my private project, I have mocked that up so far that I don't even need any MCU hardware for testing the application layer. ^^
QuanticoCEO32From the guy who wrote all the Programming Microsoft books and the Annotated Turing book. Comes this book. Th...
QuanticoCEO35Forgot to post a book yesterday, so maybe I’ll post two books today... Anyway, this book, I found it recen...
QuanticoCEO25From NAND to Tetris.. This book is IMO the best book for those who want to venture to the lower level program...