Conversation
igorpeshansky
left a comment
There was a problem hiding this comment.
Thanks. Please try to apply each comment everywhere it makes sense.
| std::string Encode(const std::string &source); | ||
|
|
||
| std::string Decode(const std::string &source); | ||
| //std::string Decode(const std::string &source); |
There was a problem hiding this comment.
Why did you decide to comment this out?
There was a problem hiding this comment.
The definition is commented out, so I thought I would reflect that in the header file. It seemed wrong to have a declaration with no definition anywhere.
I don't feel tied to this - happy to change it back.
There was a problem hiding this comment.
Let's uncomment this. To be honest, I've also uncommented the implementation and tested it in my private clone, and it works fine, so we might as well make it available, even if we don't yet use it.
Want me to push the commit that does that?
| TEST_OBJS=$(TEST_SOURCES:$(TEST_DIR)/%.cc=%.o) | ||
| TESTS=\ | ||
| format_unittest | ||
| format_unittest\ |
There was a problem hiding this comment.
Let's add a space before the \.
| namespace { | ||
|
|
||
| TEST(EncodeTest, EmptyEncode) { | ||
| const std::string empty_str(""); |
There was a problem hiding this comment.
May not be worth naming the constants... How about just inlining them into the EXPECT_EQ? I.e.,
TEST (EncodeTest, EmptyEncode) {
EXPECT_EQ("", base64::Encode(""));
}?
| ); | ||
| } | ||
|
|
||
| TEST(EncodeTest, NoPaddingEncode) { |
There was a problem hiding this comment.
Do you want to add a comment explaining the "no padding" bit? E.g., // 5 bytes should produce 7 characters.
There was a problem hiding this comment.
I've been trying to come up with a good name for the "padding" tests... The best I got so far is "phantom" (as in "phantom characters at the end"). So this test would have been named "OnePhantom", and the double padding one below would become "TwoPhantoms". WDYT? Happy to hear suggestions for better names. Ultimately, I think we ought to explain what we're testing in a comment if the test name isn't sufficiently expressive.
Your comment explains "no padding", but not the difference between the single and double pad characters.
There was a problem hiding this comment.
Phantom sounds good to me. Hopefully the new comment is more clear.
| ); | ||
| } | ||
|
|
||
| TEST(EncodeTest, NoDoublePaddingEncode) { |
There was a problem hiding this comment.
Why "double padding"? Can you please elaborate?
There was a problem hiding this comment.
Sure: Typically this would have "==" as padding, hence the "double" as opposed to the above which would have "=" (single). I guess its kind of a trivial case, happy to remove it.
There was a problem hiding this comment.
I think it's an important corner case and needs to be tested, but see my other note about test naming.
| std::string Encode(const std::string &source); | ||
|
|
||
| std::string Decode(const std::string &source); | ||
| //std::string Decode(const std::string &source); |
There was a problem hiding this comment.
Let's uncomment this. To be honest, I've also uncommented the implementation and tested it in my private clone, and it works fine, so we might as well make it available, even if we don't yet use it.
Want me to push the commit that does that?
| namespace { | ||
|
|
||
| TEST(EncodeTest, EmptyEncode) { | ||
| EXPECT_EQ( |
There was a problem hiding this comment.
Let's save some vertical space and put this whole EXPECT_EQ on a single line. Ditto below.
| ); | ||
| } | ||
|
|
||
| //Base64 encodings typically pad messages to ensure output length % 4 == 0, our |
There was a problem hiding this comment.
Nit: missing space after comment marker.
| } | ||
|
|
||
| //Base64 encodings typically pad messages to ensure output length % 4 == 0, our | ||
| //implementation does not |
There was a problem hiding this comment.
Nit: missing trailing ".".
| ); | ||
| } | ||
|
|
||
| TEST(EncodeTest, NoPaddingEncode) { |
There was a problem hiding this comment.
I've been trying to come up with a good name for the "padding" tests... The best I got so far is "phantom" (as in "phantom characters at the end"). So this test would have been named "OnePhantom", and the double padding one below would become "TwoPhantoms". WDYT? Happy to hear suggestions for better names. Ultimately, I think we ought to explain what we're testing in a comment if the test name isn't sufficiently expressive.
Your comment explains "no padding", but not the difference between the single and double pad characters.
| ); | ||
| } | ||
|
|
||
| TEST(EncodeTest, NoDoublePaddingEncode) { |
There was a problem hiding this comment.
I think it's an important corner case and needs to be tested, but see my other note about test naming.
| } | ||
|
|
||
| // Base64 encoders typically pad messages to ensure output length % 4 == 0. To | ||
| // acheive this, encoders will pad messages with either one or two "=". Our |
There was a problem hiding this comment.
Let's stick to one space after "." (throughout).
supriyagarg
left a comment
There was a problem hiding this comment.
A very minor comment., otherwise LGTM.
| } | ||
|
|
||
| // Base64 encoders typically pad messages to ensure output length % 4 == 0. To | ||
| // acheive this, encoders will pad messages with either one or two "=". Our |
Also fix bug in alternate base64::Encode implementation and enable base64::Decode.
Add testing for base64 encoding. Remove base64 decoding from header file to reflect its commented out implementation.