Hacker News new | comments | ask | show | jobs | submit login

This is an honest question, I'm not trying to be negative but I'm really confused.

It would seem like best practices is that all of this is part of your automated tests. Tests that are checked in to your repo and written in code and part of your CI. How does a native app that is OSX only fit in that scenario? Or maybe I'm not understanding it?




As ing33k mentioned, Paw isn't an automated testing tool (at least not yet), but rather an app where you can experiment with your or others APIs to check if things are working, and have a visual feedback/confirmation of what you're doing.

But that's actually a great question. We are asking ourselves the same here at Paw: should our app offer a testing/assertions feature?

Our own server backend is in Django using the Django REST Framework (it's an amazing tool btw) and clearly unit testing done inside the web framework is the right thing to do. Good frameworks have mocking libraries, and unit tests allows you to exercice all parts of the code (not only API facing). So why testing in an app like Paw? And should we encourage "bad practices" with a new feature that encourages users to have request/response assertions in our app instead proper unit tests?

First, everyone isn't writing tests ;) And sometimes maybe for good reasons (quickly putting together an MVP…). Assertions can be a quick alternative before writing proper unit tests. But mostly, we were thinking about assertions in Paw as a great way to do quick integration testing. For example, we've released Paw 3 recently, pushed server updates on an hourly basis, and we had no way to verify after a deploy that all the website's pages were up and that API endpoints were behaving as expected. Sure, the CI was saying that tests are passing, but who knows if someone has changed settings on AWS or on 3rd party tools (Stripe, Algolia…)? We would have loved to have assertions ourselves…


Testing would be great. I have no use for team syncing, so won't upgrade to the subscription version, and use Paw as dev tool when working on new APIs. Having tests in there would be convenient and would actually make me test things (I have a hard time making or updating unit tests, I admit). If it was able to continuously monitor my API server side, for at least when I push a commit, that would be great. I'm currently using Runscope for this a bit, but it's flaky and a bit too expensive for my light use. And of course I have to manually re-add everything I already did in (much more powerful) Paw.


imo Paw is not an automated API testing tool. You can use it to explore/browse API's. Developers after creating a new endpoint or after editing an existing endpoint want ways to easily send a properly constructed request and visually check the returned response (mostly json these days ).

There's a feature in Paw which let's you generate code in multiple languages for any request that's already in Paw. May be people are using it as a starting point to write tests.


I'm guessing this is more for in development or debugging issues.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: