-
Notifications
You must be signed in to change notification settings - Fork 72
New cluster/handoff CLI coverage #711
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
Conversation
|
Reviewing |
|
Looks like something has changed. Here's a test run against EE 2.0.4 tag: |
|
Hmm, this looks a bit hairy. Will have a think on it. OK, so the current test grabs the output from rt and does some simple comparisons. For example... The tests for riak-admin member-status use this intercept which is implemented here and quoted below: verify_console_member_status(Val) ->
case Val of
[] -> ?PASS;
_ -> ?FAIL
end.Each one of the console commands is hooked to its implementation function. With the new handoff commands we are interacting with just a single function |
|
@mrallen1 I think I see your confusion. I took a look at the tests as well and the output of those intercept function calls can't possibly match In our case, since we only call one function from nodetool and the parsing and callbacks are handled by clique, we'd have to make sure we intercept the registered callback called from clique. However, since clique handles parse errors automatically and won't call the callback in that case, we couldn't do negative testing this way. It would however test that the commands are actually registered correctly and get called when given a correct command line string. I'd give that a try. You wouldn't even have to check that the arguments were right. If the function got called it is correct, so you just return ?PASS. |
|
I'm now wondering what happens if the intercept doesn't fire because a bad string is passed. I was thinkng there would be a timeout, and the test would fail, but now I'm not so sure. I bet if it's just not called and the test passes. In that case it makes these tests pretty useless, since you can't tell when they actually pass or fail. Something to look into @mrallen1. |
|
OK, thanks @andrewjstone - I will check into it more closely tomorrow. |
Not ideal but better than nothing.
|
@andrewjstone @macintux Please review. This is what I'm getting: ⚡ |
|
@mrallen1 After looking at the comment at the top of this file, which I should have done in the first place, I realize that this test is only intended to check for bash portability bugs via intercepts. That's why it only checks the input to the intercepted function, as I noted in my previous comments. Your tests check the output of the calls to ensure they return something. So while they do indeed prove that a correct round trip call occurred, they are quite brittle as they break with a changing message, which is not really the thing we are gaining by testing with them. As noted, handoff commands aren't directly parsed by bash, so the original purpose of the test is not necessary for our new clique based commands. Since they aren't really useful for the purpose of this riak_test, and are very brittle, I'd say we just don't bother updating this test the new cli stuff at all. |
|
Mark and I discussed the incongruity of his tests vs what was being done already; thanks for catching why. I agree, makes more sense rely on clique's tests. Fortunately, Mark and I both learned a fair bit about the intercepts and riak_test in general while working on this, so definitely not wasted energy. |
|
OK, in light of that, I'm going to close this PR. Thanks for the feedback. |
Add CLI test coverage for the new handoff and cluster commands added in riak_core from basho/riak_core#659, basho/riak_core#660 and basho/riak_core#661. These commands include
There is also coverage for the "set / show / describe" cuttlefish configuration values in riak_cli.
Also tracking #707 (this PR may conflict depending on merge order.)