Added unit test infrastructure #24
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
That way, the list is much more easy to read and diffs (when adding new packages) are much more obvious. It's not a problem with the vertical space in this file anyway.
cmocka (http://cmocka.org) is a unit testing framework for C which seems to be actively maintained and reasonable. Let's give it a try, since there are very clear areas in the chaos system that would be much easier to maintain with unit testing/TDD in place.
This has been suggested as a FIXME in one of the Rakefiles. Now, we're moving towards this, by taking small steps, one at a time. This fix supports both scenarios - CFLAGS can be an array, or a string, and the common_rules.rake file will support both ways.
…mes. Also started doing some cleanup in the Rakefile.
…ilds can work again.
The right approach here would be something like http://stackoverflow.com/a/1139148/227779 but this should also work, even though it is not the proper way to do it.
… tests. This also involved some "moving around" of methods, so that they are listed in the order in which they are called. The code is IMHO more readable that way.
Function prototypes are really only a necessary evil. For methods defined in unit tests, they serve no other purpose than to make one annoyed about the fact how primitive the C programming language is.
After all, this is unit tests. Adding this warning does not add any value whatsoever.
Weak symbols are quite useful for this. I looked into using the --wrap function in GNU ld instead, but the problem is that it only works for *undefined* functions, and I don't want to have to mess around with linking a special .a file just for the tests. So making them weak and just overriding them is simpler (since I have need for calling the underlying methods; at least not yet).
…eallocate. This is unfortunately all but trivial. The problem is that the code hasn't really been written with testability in mind. Is it worth it? one may ask. "I don't know" is the simple answer. In some ways, yes: it makes sense to have an infrastructure for tests so we can easily (at a very low cost) add more tests later. But maybe this (memory_global_allocate et al) are just a few bad examples and it would make more sense to add tests for e.g. string_to_number and such - methods which have very few external dependencies etc.
perlun
added a commit
that referenced
this pull request
May 2, 2015
…tructure Added unit test infrastructure
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds infrastructure for unit testing, plus 5 very simplistic test cases. It's now trivial to add more as we go along. Can be good when working with the existing code base, to try and squeeze out bugs.