Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MinUnit – A minimal unit testing framework for C (2002)

jera.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: MinUnit – A minimal unit testing framework for C (2002)

#41

Post by giancarlostoro »

tonyedgecombe wrote: post #35
giancarlostoro wrote: post #16

And then in D it's built-in to the compiler so it's a 1 liner of sorts: unittest { ... } and they all run during compilation. https://dlang.org/spec/unittest.html

I'm surprised that isn't used in other languages, having the test right next to the code seems such a good idea.

Rust went this path too, there's something I love about having unittesting readily available. I can choose to use it or not use it. My asserts are available to me as I so desire. Python too sorta has some unittesting in the standard library, but that's not a compiler level thing.

Re: MinUnit – A minimal unit testing framework for C (2002)

#42

Post by slavik81 »

makmanalp wrote: post #39
masklinn wrote: post #31

Earlier quoted context omitted.

That's why I love pytest. You just `assert` an expression, and on failure it'll break down each sub-expression and show whatever it yielded, plus by default it captures all output (stdout and stderr) and prints it out only on failure (so logging and other console output is not painfully annoying while testing) and the fixtures systems is just fantastic and parameterised tests make for much clearer data-driven (/table…

On top of that, it'll compare complex structures to each other, so you could have a very large list of dicts that contain a custom data structure and it'll show you a diff and exactly where the mismatch is. Then it can auto-drop to the debugger and you can inspect previous variables to inspect the root cause, if not immediately apparent. Going back to C land, as much as I enjoy it, the tooling feels like the stone ag…

Static reflection is one of my most looked-forward-to features in C++2x. All the information needed to introspect complex data structures is available to the compiler. We just need a way to access it.

Re: MinUnit – A minimal unit testing framework for C (2002)

#43

Post by sctb »

mikestew wrote: post #25
VictorSCushman wrote: post #23

I have a library [link redacted] that was originally designed to extend MinUnit. I love the idea of an all-in-one unit testing library without complicated set up.

Well, there's a fine welcome from HN: new account that's fifteen minutes old, which posts what could be useful information (I just skimmed it) in a non-controversial manner and...insta-dead. I obviously vouched for the comment, but yeesh.

I hear you, but since we don't have software that can determine whether posts follow the guidelines, sometimes (especially for brand new accounts) the anti-abuse software gets it wrong so then we have vouching.

Re: MinUnit – A minimal unit testing framework for C (2002)

#44

Post by VictorSCushman »

mikestew wrote: post #25
VictorSCushman wrote: post #23

I have a library [link redacted] that was originally designed to extend MinUnit. I love the idea of an all-in-one unit testing library without complicated set up.

Well, there's a fine welcome from HN: new account that's fifteen minutes old, which posts what could be useful information (I just skimmed it) in a non-controversial manner and...insta-dead. I obviously vouched for the comment, but yeesh.

Thank you :)

Re: MinUnit – A minimal unit testing framework for C (2002)

#45

Post by mikestew »

sctb wrote: post #43
mikestew wrote: post #25

Earlier quoted context omitted.

Well, there's a fine welcome from HN: new account that's fifteen minutes old, which posts what could be useful information (I just skimmed it) in a non-controversial manner and...insta-dead. I obviously vouched for the comment, but yeesh.

I hear you, but since we don't have software that can determine whether posts follow the guidelines, sometimes (especially for brand new accounts) the anti-abuse software gets it wrong so then we have vouching.

Yeah, I get what you're up against (I do skim New once in a while). Just a good thing someone has Show Dead on and has sufficient points to vouch, eh? :-)

Re: MinUnit – A minimal unit testing framework for C (2002)

#46

Post by kernelbandwidth »

simias wrote: post #22
vortico wrote: post #9

Why not just 1 line? Of course, the application will halt after one test fails, but some people like it this way. #include Usage: void test_foo() { assert(foo() == 4 /* foo should be 4 */); } Output would be something like Assertion failed at "foo() == 4 /* foo should be 4 */" If you run the application in a debugger like GDB, you can see the frame when the abort trap is called.

I actually implemented a basic unit test framework in C yesterday and started with basic asserts like you point out, however once I got it working I switched to return values not unlike TFA. The obvious problem with assertions in that they kill your test program immediately at the first failure instead of doing additional tests and potentially give a clearer picture of what's broken exactly. They're also not very fle…

Assertions don't actually have to kill the program. They send an abort signal, which means you can catch them with a signal handler.

I similarly wrote a simple C testing framework for a little project I was working on, based on assertions. The framework uses signal handlers for aborts and segfaults, and then setjmp/longjmp to handle resuming the test suite at the next test case. This has the particularly nice effect of turning segfaults into (marked as such) test failures, instead of just terminating everything. It probably wouldn't be too hard to fit custom messages in too, but I hadn't felt the need yet.

Re: MinUnit – A minimal unit testing framework for C (2002)

#47

Post by marmaduke »

kernelbandwidth wrote: post #46
simias wrote: post #22

Earlier quoted context omitted.

I actually implemented a basic unit test framework in C yesterday and started with basic asserts like you point out, however once I got it working I switched to return values not unlike TFA. The obvious problem with assertions in that they kill your test program immediately at the first failure instead of doing additional tests and potentially give a clearer picture of what's broken exactly. They're also not very fle…

Assertions don't actually have to kill the program. They send an abort signal, which means you can catch them with a signal handler. I similarly wrote a simple C testing framework for a little project I was working on, based on assertions. The framework uses signal handlers for aborts and segfaults, and then setjmp/longjmp to handle resuming the test suite at the next test case. This has the particularly nice effect…

It would be safer to fork before the segfault, to preclude other less obvious memory errors.

Re: MinUnit – A minimal unit testing framework for C (2002)

#48

Post by lotyrin »

bramblerose wrote: post #33
a_imho wrote: post #24

Earlier quoted context omitted.

OTOH never rule out how KISS is the enemy of billable hours and don't underestimate CDD's ability (consultability driven development) to come up with solutions to non problems. YMMV, the BDD implementations I've seen so far did not convince me of its value to put it mildly.

I never understood the value of Gherkin/Cucumber style testing until I worked with a QA engineer. The engineer started writing the tests (in Cucumber format) as a way to write __manual__ tests: they allow you to write 'do this, then that, verify this' in a structured manner. Automating this was a secondary goal: once you have (relatively) structured manual tests, it's nice if you can automate them, while still retain…

Yep. The value of Given When Then ends, not begins, once you have implemented the steps with some automation.

Re: MinUnit – A minimal unit testing framework for C (2002)

#50

Post by sidlls »

tonysdg wrote: post #18
sidlls wrote: post #15

Earlier quoted context omitted.

You're describing "fluent programming" ("it().shouldEqual(x)..."). Unfortunately it's not just unit testing frameworks where this nightmare exists. Plenty of production code abuses the builder pattern to have this "it's like reading English" stuff.

It's not really that terrible of a concept -- some of the earliest high-level languages (e.g., COBOL) were designed to be "readable" by less-technical staff. It just requires careful design and structure. IMO, it only falls apart (and becomes such a nightmare) because of the imprecision of spoken & written word. Computers don't understand idioms, colloquialisms, and the like, and so non-technical staff are tricked in…

This sort of programming seems popular with languages that are already verbose (Java), and it just adds pointless extra verbosity.
Post reply on HN