New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding basic framework for unit tests #24
Conversation
@@ -0,0 +1,3 @@ | |||
#!/bin/sh | |||
|
|||
gdb --args build/debug/test/tester ion-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about platforms that don't look like gcc?
Scripts like this really should have a file extension (e.g. .sh
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea? I figure we'll cross the cross-platform bridge when we come to it, just getting the code to compile is a more likely first step than getting debugging working. Or did you mean just add "-gdb" to the file name so that it's clear what's going on?
I'll add the file extensions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is there should be some kind of TODO, issue, or event a mention at a minimum that this is specific to a particular platform and we'll support other platforms in another way.
We don't need to support all the platforms this second, but we should be thinking about what we need to do for the ones we need to support.
When a test fails do I get some clue as to what broke. I'm guessing I do as a result of Should we be using a C unit testing framework of some sort? I am somewhat ambivalent since I don't like additional dependencies, but we should at least evaluate if any would be reasonable and make our lives easier. |
We already a have a (very rudimentary) unit test setup with counters for suites and tests, I'd prefer to augment that than take any additional dependencies. I've beefed up the assertions so that useful error messages will be output, and I've converted them to macros so that we can get accurate line number information. |
Example output: Wrong uint64 length: Expected 1 but was 3 (ion_binary_test.c:21) ion_binary_test over (null) Value COUNT: 1 FAILURES: 1
iERR test_ion_binary_len_uint_64() { | ||
iENTER; | ||
|
||
IONCHECK(ASSERT_EQUALS_INT(0, ion_binary_len_uint_64(0LL), "Wrong uint64 length")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the IONCHECK go inside the assertion?
Looks like a good start to me. |
No description provided.