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 7be64d4b11ccef966fd98f502aad7c10ef120073 on kurtmckee:test-ulist into 62944bc931ddf02bae73f97a15069f3f9493cc63 on LudovicRousseau:master.

[LudovicRousseau]

Yes, ulist can be removed and replaced by native Python sets. See my comment in https://github.com/LudovicRousseau/pyscard/issues/195#issuecomment-2380644092

[kurtmckee]

I'm working to capture the state of the package before I begin to make changes. :+1:

[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 4c65f6f506a79376d0ca4cc912cb422267fefd96, 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 8c6e25945dbfcda996c3351027a3b3b0c168a733

Thanks