-
Notifications
You must be signed in to change notification settings - Fork 178
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
Test cleanup #240
Test cleanup #240
Conversation
A commit over 4 years ago disabled most of the eunit tests in the eleveldb module. This enables them and adds a few, while refactoring so they clean up after themselves. It also adds exported test helper functions to make it easier for other tests to clean up after themselves.
Tests now use helper functions from eleveldb module tests.
…time out on wimpy builders.
- Number of database instances is capped to keep filesystem footprint manageable. - Complexity of some operations reduced to limit runtime. - Generous timeouts added to more tests.
Looks good! 👍✅ MERGE
|
I have executed the buildbot automation against this branch. There were 4 failing platforms out of 16. This is the typical count. I manually reviewed the failing four. Two executed fine upon manual retest. The other two (smartos1.8 and freebsd10) were typical resource problems. Not going to sweat it. I +1 from the automation viewpoint. |
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.
Just some stylistic/consistency notes on formatting - otherwise looks good.
%% Exported Test Helpers | ||
%% =================================================================== | ||
|
||
-spec assert_close(DbRef :: db_ref()) -> ok | no_return(). |
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.
The "spec, comments, function" pattern you're using for some reason really messes with me - we almost always have doc comments above spec and function declarations. Can you please swap these around and, where they are public functions (maybe not too many) make them @doc
comments?
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.
Only other thing (and again, general style note) is that left-aligned comments generally have 2 %
characters, so all the comments above functions should be double-%
- some sort of emacs-mode standard, and things can get messed up if you aren't consistent about it.
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.
All 42 tests pass locally... if you could do the minor cleanup stuff I'll +1.
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.
I use a single %
prefix when it's not published in edoc.
If it doesn't have a %% @doc
comment, it's because it's not exported in all cases, and edoc will blow up on it. Basically, anything within the -ifdef(TEST).
block with any edoc comments causes failure (edoc's not very smart sometimes).
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.
The "spec, comments, function" pattern is not at all uncommon in Erlang code, and I use it because I find it easier to digest when the spec doesn't run immediately into the code
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.
Problem is it's not common in Basho code - we pretty much universally do it the other way (comments then spec then function) - consistency with the rest of the codebase is important. Same goes for 2 %
symbols for left-aligned comments (even when not @doc
comments) - I've almost never seen single-%
comments in our codebase, which is why it stuck out at me like a sore thumb.
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.
I refer you to the edoc documentation:
Examples:
-spec my_function(X :: integer()) -> integer().
%% @doc Creates ...
The first example shows the recommended way of specifying functions.
There may be more of it in our source base than you think - it's not all from me.
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.
The latest commit takes care of the comment format.
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.
Please go take a look at almost any other use of a -spec
and a comment above a function in our codebase (specifically, modules starting with riak_
since we "own" those more than others)... In every case I've looked at (and I'm at about 100 instances of -spec
so far) it's doc/spec/function. I think keeping consistent with the rest of our codebase is important enough to spend some time swapping these around.
…Doug and/or emacs happy (the former is the more worthy goal). Sync with latest 'develop' branch.
Looks good! 👍✅ MERGE
|
+1 |
This started with fixing tests to NOT leave test files all over the place, but it quickly became apparent that many of the tests weren't running at all.
Turn off whitespace diffs by appending
?w=1
(or&w=1
, as appropriate) to the URL.With these changes:
/tmp
and clean up after themselves.badmatch
are now enclosed in appropriate?assert...
macros.Note: This does nothing about the cuttlefish kludge, sorry MvM.
This PR replaces #239 with a branch name that should be compatible with all builders.