i dont know whether it makes any sense or not but for any beginner your content is GOLD. Sometimes one can wonder that should i continue making this content when the views are limited and there is a looooot of effort goes into making even a single video. but trust me dear your work is a veryyyy big help and i can say for hundreds of others like me who feel the same way just not expressing enough.
Bunch of test frameworks to choose from Gtest, unity, cunit. Which one to choose from? Need to keep an eye on integration test as well. @samek please also schedule one series for python or perl script for automation.
Which testing framework? How about ET ( github.com/QuantumLeaps/Embedded-Test ). It is simple, but as capable as Unity. (Support for "mocking" in ET will be added in the future). Regarding using Python for testing, I've already made some videos: "Testing of Event-Driven Embedded Software with Python", Part-1 ( th-cam.com/video/dt7Vy02W5DU/w-d-xo.htmlsi=rbYd1OktGAJA6_Cy ) and Part-2 ( th-cam.com/video/1L4bAOZHdIc/w-d-xo.htmlsi=mhaj-jdUIYT4GKgZ ) --MMS
Ceedling is really great too and remove the need to add every tests manually (Ceedling use Unity and Cmock...) given the title I expected this video will speak or mention something about it 😅
@@JuPrgn I don't have a video about Ceedling yet, but I do about "mocking" with Unity and Cmock (see th-cam.com/video/dt7Vy02W5DU/w-d-xo.htmlsi=qCLxTn8V3EEbcIqk&t=578 ). But to inform viewers unfamiliar with Cmock and Ceedling, they are written in Ruby.
@@StateMachineCOM I love your video I am a bit late (did not watched all yet) cause I discovered your channel 3 months ago but you have great teaching skills and your content is really valuable !
Thank you for bringing up QUTest. I didn't mention it in this introductory video about testing because QUTest is a bit more advanced and more innovative than the traditional approach based on the xUnit heritage. QUTest is also not related to ET, which is much more like the other traditional testing frameworks, so it should feel more familiar. The two testing approaches (QUTest based on software tracing) and ET (based on the traditional xUnit) are complementary and useful for different things. ET is good for testing low-level algorithms (e.g., the "ring-buffer" implementation mentioned in the video). QUTest is much better for testing interactions, such as those occurring in event-driven systems. --MMS
Happy new year, and thanks for the overview to the testing topic. What is your opinion to the fuzzing subject with tools like AFL++ in the embedded system section?
I'm not familiar with AFL++ and have never seen it used for embedded software. But anything that finds defects could be potentially valuable. It seems that AFL++ would require testing on the host, which confirms the usefulness of "dual-targeting". --MMS
Code coverage can be recorded by adding the option --coverage to the gcc compiler (in the Makefile). This will generate coverage data in a file, which you can analyze with the utility called gcov. Please google for "gcov". All this will work on the *host* computer right away (that's why I always recommend the "dual targeting" technique.) Obtaining coverage in an embedded target is possible, but more involved and ET currently does not support it. --MMS
i dont know whether it makes any sense or not but for any beginner your content is GOLD. Sometimes one can wonder that should i continue making this content when the views are limited and there is a looooot of effort goes into making even a single video. but trust me dear your work is a veryyyy big help and i can say for hundreds of others like me who feel the same way just not expressing enough.
I love this series so much. Have been tuning in since episode 1! It's so broad and comprehensive.
Still as a senior embedded software developer, your videos are amazing. Thank you.
Thank you. Looking forward for next series on UT!
❤Excellent thought process, disruptive
Happy new year 🎉
Bunch of test frameworks to choose from
Gtest, unity, cunit. Which one to choose from?
Need to keep an eye on integration test as well.
@samek please also schedule one series for python or perl script for automation.
Which testing framework? How about ET ( github.com/QuantumLeaps/Embedded-Test ). It is simple, but as capable as Unity. (Support for "mocking" in ET will be added in the future).
Regarding using Python for testing, I've already made some videos: "Testing of Event-Driven Embedded Software with Python", Part-1 ( th-cam.com/video/dt7Vy02W5DU/w-d-xo.htmlsi=rbYd1OktGAJA6_Cy ) and Part-2 ( th-cam.com/video/1L4bAOZHdIc/w-d-xo.htmlsi=mhaj-jdUIYT4GKgZ ) --MMS
Ceedling is really great too and remove the need to add every tests manually (Ceedling use Unity and Cmock...) given the title I expected this video will speak or mention something about it 😅
@@JuPrgn I don't have a video about Ceedling yet, but I do about "mocking" with Unity and Cmock (see th-cam.com/video/dt7Vy02W5DU/w-d-xo.htmlsi=qCLxTn8V3EEbcIqk&t=578 ). But to inform viewers unfamiliar with Cmock and Ceedling, they are written in Ruby.
@@StateMachineCOM I love your video I am a bit late (did not watched all yet) cause I discovered your channel 3 months ago but you have great teaching skills and your content is really valuable !
3:30 gold!
Hello Miro, Great video . at 18:33 I was expecting it would report the test result to your QuTest tool. Does QuTest utility work with ET? Thank you
Thank you for bringing up QUTest. I didn't mention it in this introductory video about testing because QUTest is a bit more advanced and more innovative than the traditional approach based on the xUnit heritage. QUTest is also not related to ET, which is much more like the other traditional testing frameworks, so it should feel more familiar. The two testing approaches (QUTest based on software tracing) and ET (based on the traditional xUnit) are complementary and useful for different things. ET is good for testing low-level algorithms (e.g., the "ring-buffer" implementation mentioned in the video). QUTest is much better for testing interactions, such as those occurring in event-driven systems. --MMS
Happy new year, and thanks for the overview to the testing topic.
What is your opinion to the fuzzing subject with tools like AFL++ in the embedded system section?
I'm not familiar with AFL++ and have never seen it used for embedded software. But anything that finds defects could be potentially valuable. It seems that AFL++ would require testing on the host, which confirms the usefulness of "dual-targeting". --MMS
Does ET have a code coverage output?
Code coverage can be recorded by adding the option --coverage to the gcc compiler (in the Makefile). This will generate coverage data in a file, which you can analyze with the utility called gcov. Please google for "gcov". All this will work on the *host* computer right away (that's why I always recommend the "dual targeting" technique.) Obtaining coverage in an embedded target is possible, but more involved and ET currently does not support it. --MMS