Benno Rice always seems to come up with a great talk! I'm beginning to think you could say "Benno, can you do us a talk about vacuuming your stairs?" and at the end of it we'd all say "that was really interesting and kinda funny"...
Having experience writing unit tests for C I may also add: avoid globals like the plague it is and if you do have globals, make the fixture of the code that uses it reset the entire thing every single unit test. I've had far too often that if the testing order changes, half the unit tests suddenly fail because some unit test was dependent on some other unit test being run first.
This is the challenge I’m facing in the legacy C codebase I’m trying to figure out how to test. Not only is the entire thing built around globals, but they are nearly all referenced by extern calls instead of included headers
@@Seff2 as far as code functionality goes, technically it doesn’t matter since it compiles and runs. But it’s a significant negative impact on readability, maintainability, etc. I can also imagine a scenario where you could include one header with all the globals in production and swap info via header files for testing, which could be harder with externs.
It's amazing how many people ignore what you just posted, all of which ought to be common sense. Global variables (incl. "Singleton," "Monostate," etc.) are a necessary evil at best and should be avoided where possible, and contained otherwise. There are a handful of exceptions (a process-global logger, read-only data that cannot possibly change), but even then, one should use handles to the data wherever possible.
Very good presentation. I failed my first interview because they wanted me to do unit testing in C and I was claiming it couldn't really, truly, be done and that we had not tested that way in my previous job. To be fair my previous job was very close to hardware so our tests consisted of "does this LED blink when I want it to"?
My job is low level embedded too but I promise you that we’d have stern words if you said you can’t do unit testing in C (or even assembly code!). I promise you can and it’s not even as hard as it sounds. The main thing is to have a database file of preconditions (states) and expected postconditions (Boolean functions on the states) for each function call. The function signatures can be declared in the unit tests files or via headers. There is no need to add unit testing logic into the source files for the functions to be tested - and indeed that would be very bad because it mixes a the purpose of one file into two tasks which is a nightmare to debug or analyse.
cmocka supports link time mocking, but it gets ugly when people write tests that directly mock the internal implemention. If you that then your tests won’t help you if you refactor during code because you don’t test the API as you should.
I dunno... it fills me with some kind of feeling of (comedic megalomaniac voice) "ha ha ha... revenge is mine!" ... after all those times that C programmers have derided my Pascal, my Ada, my Assembly Language and, most of all, my JavaScript... it's "nice" to see the C programmers get some of those decades of derision back. ?????? ;) ?????????
What point of making unit tests for C? It's blazing fast, just cover it with integration/e2e tests, so you will benefit from its basic feature, not struggling with accidential complexity(which is also C's feature) with unit testing
@@krumbergify Of course integration tests will not show exact place where it gone wrong. But 1. You ll guess it by last diff which broke tests. 2. Unit tests will not show exact error place whatsoever, they'll be green all the time.
Benno Rice always seems to come up with a great talk! I'm beginning to think you could say "Benno, can you do us a talk about vacuuming your stairs?" and at the end of it we'd all say "that was really interesting and kinda funny"...
Having experience writing unit tests for C I may also add: avoid globals like the plague it is and if you do have globals, make the fixture of the code that uses it reset the entire thing every single unit test.
I've had far too often that if the testing order changes, half the unit tests suddenly fail because some unit test was dependent on some other unit test being run first.
This is the challenge I’m facing in the legacy C codebase I’m trying to figure out how to test. Not only is the entire thing built around globals, but they are nearly all referenced by extern calls instead of included headers
@@JKTCGMV13 does it make a difference that the variables are extern? Can't you still set them like normal variables?
@@Seff2 as far as code functionality goes, technically it doesn’t matter since it compiles and runs. But it’s a significant negative impact on readability, maintainability, etc.
I can also imagine a scenario where you could include one header with all the globals in production and swap info via header files for testing, which could be harder with externs.
Yeah...surely "avoid globals like the plague" is sound advice if you're testing or not.
It's amazing how many people ignore what you just posted, all of which ought to be common sense.
Global variables (incl. "Singleton," "Monostate," etc.) are a necessary evil at best and should be avoided where possible, and contained otherwise. There are a handful of exceptions (a process-global logger, read-only data that cannot possibly change), but even then, one should use handles to the data wherever possible.
I like testing and I like C. Great presentation sir,.
Very good presentation. I failed my first interview because they wanted me to do unit testing in C and I was claiming it couldn't really, truly, be done and that we had not tested that way in my previous job. To be fair my previous job was very close to hardware so our tests consisted of "does this LED blink when I want it to"?
My job is low level embedded too but I promise you that we’d have stern words if you said you can’t do unit testing in C (or even assembly code!). I promise you can and it’s not even as hard as it sounds. The main thing is to have a database file of preconditions (states) and expected postconditions (Boolean functions on the states) for each function call. The function signatures can be declared in the unit tests files or via headers. There is no need to add unit testing logic into the source files for the functions to be tested - and indeed that would be very bad because it mixes a the purpose of one file into two tasks which is a nightmare to debug or analyse.
first time I've seen Benno Rice actually transcribed correctly by auto-caption, and not "dinner rice"
In production!
Very good presenter!
Valgrind is my friend :)
I don't think i could test static functions with this.
cmocka supports link time mocking, but it gets ugly when people write tests that directly mock the internal implemention. If you that then your tests won’t help you if you refactor during code because you don’t test the API as you should.
I've always considered needing mocks in a unit test to be, not necessarily a code smell, but at least a slight whiff.
void fizzbuzz(int n)
{
if(n%3==0) printf("fizz");
if(n%5==0) printf("buzz");
printf("
");
}
I guess thats why its a common interview question...
That's not a function but a procedure. Thank you. Next!
It is pretty awkward that people are so opposed to C :(
I dunno... it fills me with some kind of feeling of (comedic megalomaniac voice) "ha ha ha... revenge is mine!" ... after all those times that C programmers have derided my Pascal, my Ada, my Assembly Language and, most of all, my JavaScript... it's "nice" to see the C programmers get some of those decades of derision back. ?????? ;) ?????????
@@edgeeffect I love C but I would never deride an Ada programmer!
Well. It would help to do such amazing presentations wearing something clean and respectful of the audience.
strdup is not part of the C Standard :)
But it do have in Unix-like world. Anyway, read the manual pages
Bei dieser Sprache braucht man eine Glückskatze
What point of making unit tests for C?
It's blazing fast, just cover it with integration/e2e tests, so you will benefit from its basic feature, not struggling with accidential complexity(which is also C's feature) with unit testing
*remote code executes on you*
I prefer e2e over unit test, this is the norm in Ruby/ Rails, but how do I e2e a game written in C?
What’s an e2e test and how does it cover all the ins and outs of every function of a app?
The happy path is easy and efficient to test using integration tests, but testing error handling or other edge cases is better done using unit tests.
@@krumbergify
Of course integration tests will not show exact place where it gone wrong.
But
1. You ll guess it by last diff which broke tests.
2. Unit tests will not show exact error place whatsoever, they'll be green all the time.
There's a strawman title. Why couldn't you?