←back to thread

460 points flykespice | 1 comments | | HN request time: 0.291s | source
Show context
3eb7988a1663 ◴[] No.44328956[source]
I think the idea is nice, but I am struggling for why I should use it. I write using Django, which has plenty of hooks for testing within the framework. Why switch to a tool which is blind to my backend and is going to create more work to keep in sync? At minimum, I lose the ability to easily drop into my debugger to inspect why a result went wrong.

There is probably something to be said for keeping a hard boundary between the backend and testing code, but this would require more effort to create and maintain. I would still need to run the native test suite, so reaching out to an external tool feels a little weird. Unless it was just to ensure an API was fully generic enough for people to run their own clients against it.

replies(4): >>44329015 #>>44329115 #>>44329352 #>>44334267 #
1. CoolCold ◴[] No.44334267[source]
There is no obligation on you to use it, especially if you have better tooling for the tasks.

For my team needs, I see benefits of using self-contained tool which doesn't require any extra modules to be installed and venv-like activated (this is a great barrier when ensuring others can use it too). Not even mention it will run fast.

Testing headers is particularly nice, so can test configuration of webservers and LBs/CDNs.