Test ulist

[kurtmckee]

This demonstrates that ulist has the following issues and needs to be fixed or removed:

• ulist cannot be instantiated (literally, ulist() raises a TypeError)
• ulist does not guarantee ordering (ulist([3]) + ulist([1, 2]) == [1, 2, 3])
• ulist does not guarantee uniqueness (ulist([1]).extend([1]) is equivalent to [1, 1])

I intend to investigate whether Python sets can be used in place of the ulist class.

[coveralls]

coverage: 62.36% (+1.4%) from 60.998%
when pulling 7be64d4 on kurtmckee:test-ulist
into 62944bc on LudovicRousseau:master.

[LudovicRousseau]

Yes, ulist can be removed and replaced by native Python sets.
See my comment in #195 (comment)

[kurtmckee]

I'm working to capture the state of the package before I begin to make changes. 👍

[LudovicRousseau]

Should I add tests for ulist if the code will be removed soon?

[kurtmckee]

These additions to the test suite put a stake in the ground for what works -- and what doesn't -- as of right now.

The reason that I'm putting so much time into this project is because I suddenly couldn't generate TOTP codes to access AWS at the command line a few weeks ago. The issue was commit 4c65f6f, which touched code that appears to have no tests.

My goal is to build up the project infrastructure and test suite to help prevent unexpected problems for myself and for others. I'm also looking strongly at code that can be removed or simplified, to reduce how much code has to be maintained.

Anyway, to answer your question: these tests help ensure that future changes to the code (like removing ulist!) can be understood better.

[LudovicRousseau]

Merged in 8c6e259

Thanks