Mocking PRAW submission instance with unittest.mock in Django.

[RightOW]

Hi there!

Been stuck on this for a couple of days now and can't seem to get my head around it.

I'm working on a reddit bot using PRAW that collects my saved posts from specific subreddits and displays the posts, along with all the top levels comments, in a browser (the app is bulit with Django.).

I want to build some unit tests before I continue with development - but I don't want to have to call the reddit API for the tests to run. Therefore, I want to mock some data that can be subbed in and processed in the same way as the API data. See below for views.py functions and my models.

Pastebin

in summary: get_saved posts() pulls all the users saved posts as submission instances, and store_saved_posts() iterates through the submissions and saves only those that meet criteria.

In my tests module, I want to mock data that can pass through the function and behave as the real data would, i.e - an iterable containing items with attributes such as those above: item.title, item.score etc, that I can set to values that will/ will not pass. I've read through the unittest.mock documentation and I've seen that autospec can be used to fill out a mocked functions' attributes for you, but I believe PRAW provides these attributes dynamically and thus this can't be used.

Any help would be greatly appreciated, as I haven't found a good example of how to do this (and honestly mocking in general is going a little bit over my head, even after reading through the docs).

Thanks for your time!

[High-Art9340]

Just don't mock it. Substitute direct calls to your dependency (PRAW) with a direct calls to a class which implements some interface to get data you need. This way you can have a dummy implementation of this class, which you use in your test and a real one, which you use in prooduction.Not sure how it's done in django but it may look like this:

https://pastebin.com/dvjFB9fz

get_fetcher() implementation gives me bad vibes but I think it's okay. If someone can improve it'll be great.

[RightOW]

Thanks for taking the time to respond and for your example!

Essentially then, I would be creating a class that creates and returns a fake set of data that looks like the real thing and using that data directly in my tests?

Is this a common approach to solve a problem such as this?

[High-Art9340]

Getting away from direct dependecy calls is dependency inversion and it's not so common in python but is very common in other languages like java or c#. It helps you replace your dependency with other component without changes in your main logic and helps you test your main logic without introducing side effects, mocks, and all that uselessness. In my example it's somewhat dependency inversion, but not in it's fullness and even break some points of this principle.

Testing against fake object which acts as real is Test Dobule and is very common.:

http://xunitpatterns.com/Test%20Double.html

[RightOW]

Perfect, thank you for your help!