Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

I love Test-Driven Development!

And because of that fact, my heart shatters into thousands of pieces, when I recognize error events on our production nodes which are pointing onto a golden hammer function in a legacy project.

This particular function has about 300 lines with a bunch of subfunction calls and instantiations of helper-classes returning information for workflow.

Refactoring this code to apply proper unit-tests requires a way bigger investment than simply deal with 30 eventlogs a day, because this kind of payment is barely used by customers of our webshop.

This fact is a little itch each day of my work.

Guess it will make me go insane one day
¯\_(ツ)_/¯

xD

Man I really wish I knew how to implement TDD. Sounds so good in theory, seems impossible in practice 😅

Ok ok ok, I will preface this by saying I am still a student so you can assume my complete and utter lack of experience.

There is all this fuss about unit testing and TDD but i still have my doubts about it. How is it that if your code works for certain inputs you can be sure that it will work for whatever can happen after deployment?

I mean, to my understanding testing can assure that some business requirements are cared for but as far as actual code correctness goes I don't see how that is achieved.

As far as i am concerned the closest it comes to complete code correctness is a mathematical type of proof but that should be impossible to be done effectively in an OO language.

How can you be sure that your code is what you think?

(If i have this all wrong please correct me)

Either I am dumb or the usage of p5.js functions makes it either hard or impossible to test with jest. Constructor properties are thrown away (which I need) and all methods are mocked, if I automock, or I've got the pleasure to mock everything inside the class. Otherwise of course jest complains that p5's color() isn't defined. And mocking everything manually is not safe in case of class changes.
Of course p5's tdd tutorial isn't helping, as it seems to mock everything.
I need like a pro/mentor or smth for this...