Testing APIs shouldn’t feel like a chore. Yet, here we are, copy-pasting URLs into Postman, manually typing headers, rebuilding request bodies from...
For further actions, you may consider blocking this person and/or reporting abuse
While I applaud the effort and I see the appeal of a playground, I think tests provide more robustness.
Maybe the library should have the option to generate tests?
Thanks for commenting! Nimbus is not meant to replace testing. They are not mutually exclusive and serve different purposes. It is meant for flows like when you want to quickly interact with an endpoint, a frontender wants to check endpoint content and interact with them when they are working on the client side of the feature, a QA wants to run pre-conditions by interacting with the APIs, etc. These things cannot be done via testing suites (integration + unit tests).
I understand it is not replacing testing. My idea for the generating test option came because the context of the endpoint is known in your library. And it can change on the fly, so that could be great to make sure tests are checking the actual features.
In the frontender case the output should be communicated. If the output is not what is communicated the fault is with the backend. They can check the output when they debug the API request, no need to enable the library.
For the QA situation, do you want QA's to set up the project on their own computer? My experience with QA people is that they test on the acceptance/test environment. If the library is enabled on a server it is used too far in the development process.
You can write end to end tests if there are situations that you can't test with less expensive tests. If you can't write tests, how can you be sure the features will keep on working in the future?
Thanks for the insight!
The philosophy of the package is to do one thing and do it well: be a playground for API interaction. Adding test generation would drift from this core purpose. Nimbus focuses on the immediate "I want to see what happens when I send this request" moment during development.
Absolutely, but documentation and real interaction serve different purposes. Even with perfect docs, developers often need to:
This is also valuable when you're NOT doing TDD, you write the code, want to see it work, then write tests. Nimbus fits that exploratory phase.
Not necessarily a local setup, as you mentioned, it can be enabled on staging environments if your organization allows it. But you're right that this is optional. The primary audience is developers during active development.
To clarify: Nimbus isn't a replacement for tests. It is about having a PLAYGROUND. It's for the exploratory phase before you write tests, or when you're iterating quickly and just want to see if something works, or when you just want to interact with an endpoint for whatever reason. Think of it like using dd() or var_dump(), you're inspecting behavior, not ensuring correctness long-term.
I have no problem with that stance. I was just thinking out loud about the testing option.
The real interaction is when you write the tests. If you need to mock a lot of things then you have a problem with the design of the code.
Write tests and if they fail fix te code. You don't need to do TDD. You can write the code and add the tests after you written the code. Why would you do a manual test and then write a test, work smarter not harder.
That was my point, your library shouldn't be enabled on a server.
I didn't check if the endpoint for the playground needs authorization or not. But even if it does it means the code is going to production, and that could become a data leak in the worst case.
My end to end test statement is not about the library but about good code practices.
I think you did a good job with the library, I just wanted to point out a few of the consequences when adding the library.
That’s not entirely accurate. A test will never represent a real interaction. Tests validate expectations; they don’t simulate the full behavior of an active system.
That approach can work, but inspecting responses through tests alone is often inefficient, especially during early development. The point of a playground isn’t to verify correctness; it’s to explore behavior against real data and context. The distinction between a Playground and Automated Tests is important here.
Developers can use it briefly during early development, or later if they need to interact directly with an endpoint with as little friction as possible and with as much kickstart as possible. It’s flexible and can be tailored to whatever needs you have.
Correct. Nimbus supports environment-based control. It’s disabled in production by default.
If preferred, it can also be installed as a development dependency via:
This looks awesome! Testing APIs inside the app environment feels like the upgrade we’ve been waiting for.
The validation rule auto-discovery and instant updates after edits — pure magic ✨
Can’t wait to try Nimbus and see how it changes my workflow.