Fortress released two major features to help QA teams and developers
collaborate and debug APIs in agile and test-driven development (TDD)
Currently, many companies experience a lag in deployments caused by the
separation between testers and developers. Testers can't start writing
API tests until developers have finished writing the APIs. API Fortress
solves the lag problem with powerful mock creation, which allows testers
and developers to work in parallel and accelerate the timeline of
Simone Pezzano, CTO at API Fortress, remarks: "QA and developers have
different skills and soft spots when it comes to test coverage. We help
developers dig into the tiny details of implementations, while testers
of all skill levels validate complete flows. With us, QA and development
can use the same software and language."
New: Mock Recording and Request Logging
API Fortress allows QA and developers to automatically convert API
traffic into API mocks and, if needed, customize the mocks for different
behavior. The platform can record traffic from any mobile application,
microservice, or website, and then use that recorded traffic can be to
generate an API test.
Traffic recording can be created with any HTTP client, including the
internal API Fortress client, Postman, Insomnia, or HTTPie.
Use cases include:
Debugging and Test Creation: Log all requests to mocks to retrieve
better insights about client/server communication and solve complex
debugging faster. Generate API tests against mock request logs: simply
log a request to automatically generate a test.
API Test Generation from
Unavailable Services: Even if an app is still in an early development
stage, or services are not available, APIs can be mocked for API tests.
Mock pay-per-use APIs during
development: Some 3rd-party APIs have a cost associated with every call,
such as Google Maps and Salesforce. Now teams can mock API services to
allow for development without needless costs.
Service Isolation: Create mocks of
multiple services, and then isolate a specific service from others to
see if a failure comes from the isolated service.