Add test cases for encoding/decoding a state vector

[phylib]

Hi @justincpresley, in your test case, you had some StateVector generation before actually parsing the TLV. I did not see a reason for that. I removed that and added a test case to check if generated TLVs also comply with the standard.

[phylib]

Hi @justincpresley, can you explain why you removed the source code comments with #2af3a18? In general I would recommend adding more documentation, eg. by using Docstring.

[justincpresley]

Hey @phylib, thank you for asking!

I do agree with you on the more documentation part. For now, major of the code is separated enough to be at understandable with the current documentation. I am not a big fan of Docstring (I have worked on many projects with it) and since I will be the major one working on this project (with security portion), I find it easier to not incorporate the Docstring way of documenting, at least not yet.

However, I took out the source code comments (for the purposes of merging) to keep the same documenting style throughout this github repo. I have noted the comments you provided though.

Feel free to add your comments back in your fork to make it clearer.

[phylib]

I have a couple of comments to your reply:

• Whether code is understandable or not should not be decided by the author of the code.
• I guess when the implementation is finished, it would make sense to move the library to the named-data GitHub account. And therefore, it would be good to have a more or less consistent code style. And Docstrings is what other libraries use. This is why I suggested that. What kind of documentation do you have in mind?
• This is only my point of view, but I think having inconsistent documentation is better then having no documentation.
• Also, I observed when postponing documentation to a later step, it is very likely that documentation is postponed indefinitely and will never come.