Question: What's the status of this...?

[carltongibson]

Hey @j4mie.

I'd like to be able to test that specs/pairs are as desired without needing to make an ORM query and then project that back to a dictionary in order to make an assertion.

It looks like this project would do the business... prepare some pairs and assert that it matches the expected repr.

I see the big warnings in the README. Can I ask what's your take on the status here? Is it just needing a bit more time, or is there some fundamental reason it couldn't work?

Thanks! 🎁

[j4mie]

Hi Carlton!

Interesting question. I guess you're dynamically creating a queryset function somehow, and then you want to assert that the queryset function you're creating is correct?

This library was very much designed for ad-hoc debugging - eyeballing and understanding what's going on when things go wrong. I imagine your thinking is to use get_repr to grab a string and then assert that it matches some other string in your tests?

There's no reason in principle why this wouldn't work, but I'd have two concerns:

1. If you have a peek at the implementation, you are fairly likely to recoil in horror. Lots of using inspect to peek inside closures, grab closed-over variables, and then turn them into strings that look just enough like valid Python that Black will format them for us. It's pretty fragile and I'm not sure I'd trust it to do the right thing in all cases. For example, I know for a fact it doesn't handle Q and Prefetch objects properly.
2. Performance. I haven't tested this at all but I wouldn't be surprised if this is pretty slow. Probably less slow than actually running queries, but it'd still be a concern and something I'd want to measure.

That said, if you want to give it a go please do, and I'd welcome any contributions to make this better. Maybe it would benefit from an "internal representation" - a data structure that represents what's going on inside the queryset function, which can either be rendered out to a string or inspected directly? If you did get it working, perhaps django-readers-debug isn't the right name - django-readers-inspect or something might be more appropriate.

A couple of other ideas I can think of that might do what you need:

1. Use a mock.Mock in place of a queryset, pass it to your queryset function, and then assert that the mock_calls looks right.
2. Use a real queryset, but instead of running it, stringify .query and then make assertions about that matching some SQL string in your tests.

Hope some of that is useful..

[carltongibson]

Hey @j4mie — good answer, thanks!

Hope some of that is useful..

Absolutely! 🦄

Now to retreat to my cave and work out what to make with it 🥳

Thanks again for creating django-readers! It's a delight 🎁