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
[list] sort list reply alphabetically (Fixes #836) #994
Conversation
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.
Nice. Just a suggestion on the tests.
tests/test_output_formatter.cpp
Outdated
"trusty-190611-1542 Running -- Ubuntu N/A\n"; | ||
|
||
mp::TableFormatter table_formatter; | ||
auto output = table_formatter.format(list_reply); |
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.
To test treatment of petenv, you could do something like the following (did not actually try it):
EXPECT_CALL(mpt::MockSettings::mock_instance(),
get(Eq(mp::petenv_key))).WillOnce(Return("trusty-190611-1539"));
And get that entry first in the expected output trusty-190611-1539
.
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 tend to keep unit tests single-purpose, this one tests that (non-petenv) instances are sorted alphabetically. I'd like to keep it that way.
If theory we could extend the …_petenv_first
tests a bit, but then again those test exactly what they should :)
Maybe we should just add a third test, that tests both sort orders together?
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.
Unit tests are indeed supposed to test "units" of functionality, but where you decide the unit is can often subjective. IMO it would be perfectly appropriate to consider the entire sorting function as the unit here.
The lexicographical ordering is implemented elsewhere, so this really only tests whether it is being called properly on our side. If you then test the petenv comes first without lexicographical ordering of the remaining entries, nothing guarantees that they work together: you could write code that passes both tests without doing both things simultaneously ("if petenv in, put it first, else sort"). IOW the conjunction of two bits of functionality is itself functionality that requires testing.
In practice some parsimony is needed when deciding unit boundaries, lest we end up testing single instructions 😉
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'll just add my $0.02 if anyone cares 😉
I've often struggled with what constitutes a "unit". Is is just a single function? Is it whatever is needed to get an end result, which could be made up of multiple functions? Over time, I've tended to go with the latter.
As such, I agree with @ricab here in that the end result is a list with the petenv always at the top regardless of name and then followed by instance names alphabetically sorted, if any. I really believe there needs be (a) test(s) to ensure the whole result is what we expect. We should have tests that exercise scenarios such as only the petenv exists or the petenv doesn't exist at all and only have other instances.
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.
Sure, which is why I suggested adding another test covering the conjuction of the two. And will do that.
I still find it important to know whether it's the alphabetical sorting, or the petenv precedence, or the conjunction of them failed, so all three tests make sense, IMO.
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.
OK, I am fine with separate testing for the conjunction.
You may want to consider parameterized tests to reduce redundancy – they could check for both properties but be fed input in those 3 separate conditions. It would also be easy to cover other limit cases too (e.g. empty input, only petenv, only a single non-petenv).
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 didn't see your edit where you added suggesting a third test covering the conjunction of the two.
I'm good with this whole testing approach 😁
auto output = csv_formatter.format(list_reply); | ||
|
||
EXPECT_EQ(output, expected_output); | ||
} |
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.
ditto
tests/test_output_formatter.cpp
Outdated
auto output = formatter.format(list_reply); | ||
|
||
EXPECT_EQ(output, expected_output); | ||
} |
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.
ditto
9f0a514
to
a02e204
Compare
Codecov Report
@@ Coverage Diff @@
## master #994 +/- ##
==========================================
- Coverage 69.64% 69.32% -0.32%
==========================================
Files 193 191 -2
Lines 7116 6984 -132
==========================================
- Hits 4956 4842 -114
+ Misses 2160 2142 -18
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #994 +/- ##
==========================================
+ Coverage 69.64% 69.66% +0.01%
==========================================
Files 193 193
Lines 7116 7120 +4
==========================================
+ Hits 4956 4960 +4
Misses 2160 2160
Continue to review full report at Codecov.
|
@ricab @townsend2010 this should be better then. |
8e91453
to
1bd5780
Compare
1bd5780
to
3c910fd
Compare
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.
OK, I am good with this. I have just a tiny request, if you feel like it, and a question. I'll wait for your reply before approving.
tests/test_output_formatter.cpp
Outdated
class CSVFormatter : public LocaleSettingTest | ||
{ | ||
}; | ||
typedef std::tuple<const mp::Formatter*, const ::google::protobuf::Message*, std::string, std::string> |
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.
It's a bit difficult to track what each element means (here and in the petenv suite). Could we maybe have a comment to help the reader?
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.
Done.
tests/test_output_formatter.cpp
Outdated
const auto param = GetParam(); | ||
const auto formatter = std::get<0>(param); | ||
const auto reply = std::get<1>(param); | ||
const auto expected_output = std::get<2>(param); |
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.
Did you mean to copy param
and then its contents? Not that it matters much, I suppose...
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.
Moved to structured bindings now. Could be even nicer with [[maybe_unused]]
and nesting, but not possible yet.
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.
Thanks!
bors r+
Build succeeded |
As part of that, refactor the formatter test suite into a parametrized one.
Take that, C++ tests!