Ply is meant to be easy
We invented Ply because automated API testing should be a pleasure. Not a laborious exercise in field-by-field response validations. If tests are easier to build, they're more likely to be comprehensive.
Postman, Insomnia and Thunder Client are awesome tools for sending HTTP requests. Where they fall short is in automated testing. Ply is secure and open-source. No sign-up. No need to export collections for committing to Git. Artifacts are saved directly as human-readable YAML files. Use file system folders to naturally and intuitively organize requests and flows.
|Dynamic Input Values||✓||✓||✓||✓||✓||✓|
|Previous Response Refs||✓||✓||✓||✓||✓||✓|
|Import from Postman||✓||-||✓||✗||✓||✓|
|VS Code Extension||✓||✗||✗||✗||✗||✗|
|Load Tests (Parallel)||✓||✗||✗||✗||✓||✓|
For super complex scenarios, a programmatic approach may be a necessary effort (and Ply supports that too). But for 90% of API testing Ply's workflow-driven, declarative approach is a more maintainable alternative.
For comparison let's look at a simple example: GitHub's REST API for retrieving repository topics. Ply uses YAML for expected/actual results. Here's what a similar test looks like in Postman:
were invented for. Read about Ply's intuitive support for dynamic expressions. Most importantly,
you'll want to reference properties from previous responses in subsequent requests. Like how
GraphQL query cites the
id grabbed by its upstream findRespositoryId request:
This way you can string together requests into a workflow, either declaratively in a YAML request suite, or graphically in a Ply flow.