Open aurelg opened 5 years ago
Another aspect I recently noticed is that the check_feed
helper function can only be called one time within a given test function. Any more than that and there are errors thrown regarding invalid JSON document reading. This makes it impossible to group multiple tests within a loop (like, a basic test group for all clients, as an example).
check_feed
fixed w/ b5b870b
Some additional random thoughts on this subject:
max_posts
option (both making this aspect untestable and necessarily making tests take longer than they should, since every feed item gets test-posted as a result). This also violates the first point above, as this is "less realistic" as compared to how a real run would perform/operate.post
functionality takes care of all the necessary data formatting, then directly calls the relevant client posting function. If there were another level in between that had the same parameter list for all clients (perhaps kwargs for title, content, link, tags, and media at a minimum), and then THAT function took care of the lower-level posting duties, that mid-level function could be overridden for testing purposes. Just an idea...
Problem 1
In
client_test.py
, the tests override the default__init__
function of each client withnew_init
. Among other things, thisnew_init
overrides the real provider with a fake one which just echoes what it is being sent.The return value of the
post
function of clients is consequently ambiguous:feedspora_runner:197
(suggesting that it should be a boolean as well)client_test.py
, it is tested against adict
This make the implementation of the
post
function unnecessarily complicated and fragile.Problem 2
On top of this convoluted testing strategy, the
post_test
tests also define their own way to test the clients, by passing atesting
parameter to their__init__
. Consequently, some testing-related code has to be implemented in the code being tested, i.e. in the__init__
andpost
function of each client. This is also bad practice, unnecessarily complicated and fragile.Solution
The usual solution to problem 2 is to monkeypatch the objects being tested. However, monkeypatching may cause ambiguous return types like problem 1 unless functions are specifically implemented to be easy and unambiguous to test. Since that's not the case here, this should be fixed.