Unit testing of TwitchIO

[graille]

TwitchIO 2.5 contains a lot of small bugs with data type or introduced by several updates.

I was thinking about developping a small unit test set in my project in order to test the main components I'm using in TwitchIO. But maybe it will have a bigger interest to propose a PR.

If you see an interest in such a PR, I would like to discuss which framework to prefer between pytest and unittest, which system of mock etc...

(I could also directly do this PR for 3.0 but I don't know the current maturity of 3.0 project.)

Any suggestion about this ?

[chillymosh]

Could you please give some examples of the data types that you believe to be incorrect, or all of them if you have the time.

I assume you mean models by this too.

[IAmTomahawkx]

Honestly the problem with unit testing is that it involves hijacking large portions of HTTP internals in the lib (which defeats the entire purpose of testing it), or mocking the API, which is a huge amount of dev work for very little gain.
unit testing the models doesn't really make sense as you'd just be hardcoding a payload against the model (which is basically the same as what we do when developing models). The vast majority of the bugs found in the models are actually from when I first wrote the models, as I wrote the majority of them without testing, as I don't have affiliate on twitch (this was before I discovered twitchcli). Most of these bugs have been ruled out through time and bug reports, so at this point unit tests would just end up being a burden.
the other part of the lib is the IRC aspect. Because this involves making a stateful connection, it's pretty infeasible (and not worth it) to unit test (as tests are supposed to be individual and stateless).

Long story short, our stance on unit tests had been that it's not worth the time and effort at this point. Unit tests are great for stateless libs like numpy, not so great for stateful API wrappers