4 ms·

Show HN: Drf-API-Action – New Python Web Development Testing

1 points by ori75660 3y ago

Hi HN! I’m proud to share my new first open-source project drf-api-action. This project was built as a side project at work in which we had to tweak DRF for our own needs, this project was successful back then so I wanted to publish it to everyone :) The drf-api-action Python package is designed to elevate your testing experience for Django Rest Framework (DRF) REST endpoints. With the custom decorator api-action, this package empowers you to effortlessly test your REST endpoints as if they were conventional functions. Features: Simplified Testing: Testing DRF REST endpoints using the api-action decorator, treating them like regular functions. Seamless Integration: Replacing DRF's action decorator with api-action in your WebViewSet seamlessly. Clear Traceback: Instead of getting a response with error code, get the real traceback that led to the error. Pagination Support: Paginating easily through pages by a single kwarg. Please let me know what you think/ any feedback. It means a lot since it's my first open source project :)

necovek 3y ago
First up, congrats on your first FLOSS project: a decent one at that! I wish you plenty of users and a contributor or two :) I also like that you are aiming for functional API: as you note yourself, that makes it easier to test and understand the code. The problem I have with the approach is that, instead of reducing, you are actually increasing the amount of magic in DRF. The direction I'd like to see Python projects go is more towards less magic (decorators are almost always side-effect heavy, modifying and augmenting in-place things they decorate, and those parts are rarely, if ever, tested). Basically, if DRF was done in a simpler way, there would be no need for your project since it would be obvious how to achieve the same (simpler!) thing with DRF directly. Again, this is coming from a Python veteran of 20 years who has seen Python's adaptability and dynamism take projects in all sorts of ingenious directions. But none of them has led to readable and maintainable code. Another thing that's a problem with magic is that seemingly simple functional test that should take all of 0.5ms to run is going through a bunch of code paths: this approach leads to those 2h test suites on larger projects.
- ori75660 3y ago
  thanks a lot for your feedback @necovek much appreciated! If you have any idea for reducing tests time please share, always open for new ideas :)
  - necovek 3y ago
    It's kinda obvious: have exactly the same handler function with no decorators and really test it like a pure function it is. With an existing opinionated framework like DRF, just call out to it from your handler, and have exactly one test to ensure that integration keeps working and passes parameters through properly.

1 points by ori75660 3y ago

necovek 3y ago

First up, congrats on your first FLOSS project: a decent one at that! I wish you plenty of users and a contributor or two :) I also like that you are aiming for functional API: as you note yourself, that makes it easier to test and understand the code. The problem I have with the approach is that, instead of reducing, you are actually increasing the amount of magic in DRF. The direction I'd like to see Python projects go is more towards less magic (decorators are almost always side-effect heavy, modifying and augmenting in-place things they decorate, and those parts are rarely, if ever, tested). Basically, if DRF was done in a simpler way, there would be no need for your project since it would be obvious how to achieve the same (simpler!) thing with DRF directly. Again, this is coming from a Python veteran of 20 years who has seen Python's adaptability and dynamism take projects in all sorts of ingenious directions. But none of them has led to readable and maintainable code. Another thing that's a problem with magic is that seemingly simple functional test that should take all of 0.5ms to run is going through a bunch of code paths: this approach leads to those 2h test suites on larger projects.

ori75660 3y ago
thanks a lot for your feedback @necovek much appreciated! If you have any idea for reducing tests time please share, always open for new ideas :)
- necovek 3y ago
  It's kinda obvious: have exactly the same handler function with no decorators and really test it like a pure function it is. With an existing opinionated framework like DRF, just call out to it from your handler, and have exactly one test to ensure that integration keeps working and passes parameters through properly.