3 ms·
In procedural C land, unit testing is nowhere near as relevant as it is in memory-safe OO lands. Assertions are far more relevant. You want to detect illegal pr
by bluetomcat 3y ago
In procedural C land, unit testing is nowhere near as relevant as it is in memory-safe OO lands. Assertions are far more relevant. You want to detect illegal program states in development as early as possible. In C11, you also have static_assert for things like "is this static lookup table as big as needed".
- monsieurbanana 3y agoI get why assertions would be more important than in memory safe languages, but why are unit tests less important in C than in higher-level languages? Or you just mean relative to assertions? (which to me don't really influence each other in that way)
- bluetomcat 3y agoBecause the coding style is different. The basic unit of code is the procedure, not abstract entities like DateTimeCalculator or EmployeePayrollManager. Procedures are sensitive to the context where they are called. A procedure calling another procedure usually takes care to provide valid input data. Robust error-checking must be in place, or your program is unsafe. A unit test wouldn't know the calling context of procedures deep in the call graph, and cannot detect unsafe but seemingly working code.
- vkazanov 3y agoThis is more of a culture surrounding the language than anything else. Modern C avoids global state, prefers directly specified context and even allocation is external to the function's logic. And testing functions is easy. This is as opposed to procedures, I.e. functions that operate on global state with fragile conext assumptions, which almost impossible to replicate in test environments.
- lelanthran 3y ago> The basic unit of code is the procedure, not abstract entities like DateTimeCalculator or EmployeePayrollManager. I agree, but in almost any non-trivial well-run C project the basic unit is going to be datatypes, opaque pointers, modules, etc. In that case I generally throw in a `bool MyObjectType_test(void)` into the module so, in some sense, I'll have some basic sort of testing. Not as nice as the OO languages provide, but enough to give myself some confidence that changes don't introduce blatant bugs.
- monsieurbanana 3y agoI work mostly with functional programming languages where the function is the basic unit of code, what you say is true but is also true for "abstract entities". Not all classes need robust error checking if you control how they are being called. > The basic unit of code is the procedure I think ultimately this is where we think differently. If you are okay testing a whole class in an OOP context and calling that a unit test, then a test that calls multiple procedures (because one of them creates the input for the main procedure I want to test, for example) can also be considered a unit test.
- Gibbon1 3y agoI also think because it's lower level what functions are built on tend to be long term stable. Function was tested at one point and then used in production for a couple years. It works and will continue to work as long as no one messes with it.
- hgs3 3y ago> In procedural C land, unit testing is nowhere near as relevant as it is in memory-safe OO lands. I'm not sure why you'd say this. Testing has more to do with the developer than the language. The SQLite project is written in C and has 590 times more test code than source code [1]. [1] https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html