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?
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…
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.