Spec updates, Python 3.4- unsupport & custom registries #59
Conversation
…s with new support for custom user-managed registries
|
|
||
| [testenv] | ||
| commands = pytest --cov=multiaddr --cov-report=term --cov-report=html:build/test-{envname} | ||
| commands = pytest --cov=multiaddr --cov-report=term --cov-report=html:build/test-{envname} --cov-fail-under=100 |
There was a problem hiding this comment.
Would it be necessary to have 100% coverage rate?
There was a problem hiding this comment.
Define “necessary”. 😉
On that subject, I can only say that for me, it feels a lot better to edit a codebase where it is ensured that at least every line will be run once and most dumb mistakes will be caught. On the other hand, I'm well aware that writing tests isn't most people's favourite activity (myself included) and that it slows down development. My longer term experience has however been that it has generally been worth it however.
Also, note that in this particular case most low-key contributions (like adding a new codec or protocol) will not require writing any test code at all. I fixed the coverage of that previous contribution by simply adding some valid and adverse examples to the relevant test vectors. What I'm saying is, that for most “simple” contributions the overhead for maintaining the coverage should be relatively small. For larger changes (like the ones I tend to contribute), I believe the overhead of writing relevant test is justified for ensuring the longer-term viability of this project.
There was a problem hiding this comment.
Fair enough. What I thought unnecessary are something like getters. But yeah they should at least be called once in the tests so 100% coverage should be fine.
|
|
||
| [testenv] | ||
| commands = pytest --cov=multiaddr --cov-report=term --cov-report=html:build/test-{envname} | ||
| commands = pytest --cov=multiaddr --cov-report=term --cov-report=html:build/test-{envname} --cov-fail-under=100 |
There was a problem hiding this comment.
Fair enough. What I thought unnecessary are something like getters. But yeah they should at least be called once in the tests so 100% coverage should be fine.
The custom registry support is for adding extra MultiAddr codes for specific projects that are either not applicable to general use or, as in my case, blocked on the infinitely slow speed of the MultiAddr spec repo…