How can you test APIs with complex workflows like e-commerce or financial systems?

Ideally, tests should be developed prior to the implementation phase. At this stage, understanding of the requirements is at its peak, enabling the creation of more effective tests. Additionally, this approach ensures that the tests are functioning correctly, as manual testing of the application is necessary at this point anyway.

Testing APIs in e-commerce or financial systems needs a step-by-step plan. First, learn how everything works together. Then, check each part of the system (like different APIs) to see if they work alone. After that, test how they work together. Try using the system like a real user would to see if it all goes smoothly. Make sure the APIs can handle lots of work and are safe from hackers. Keep checking regularly to ensure everything stays reliable and meets the rules. If needed, pretend or mimic things to test when the real system isn't available. This helps make sure the APIs in these complex systems work well and are safe and reliable.

In addition to writing JUnit and integration tests, it's essential to incorporate regression testing into your automation testing. When deploying an API, it should trigger regression testing for all APIs that interact with the changed one. This ensures comprehensive coverage, extending beyond your immediate domain. Another modern approach is to leverage Amazon CloudWatch Canaries, allowing you to perform synthetic testing that mimics user behavior and transactions. This method records the results of each associated API interactions, collectively validating the functionality. Perform functional testing to ensure that the API meets its intended functionality for complex workflows, especially corner cases.

One should first analyze the swagger/API specs before testing and try to understand the functionality - what the API does, what is it's input and output and based on this info all the scenarios should be created and tested.

Write a BDD scenario that demonstrates the entire workflow. Differentiate that scenario into ones for each step. Then differentiate those into ones for each component (e.g. API). You test the components, then the steps, then the entire workflow. In short, use differentiation to create tests, not synthesis (ala Alexander).

The effectiveness of a testing approach hinges on its alignment with your project's needs. Each testing method serves a specific purpose in ensuring a comprehensive evaluation of your software. Choosing the appropriate tools and techniques—be it unit, integration, end-to-end, performance, or security testing—demands a keen understanding of your system's intricacies. By leveraging the right mix of methodologies and tools tailored to your project's requirements, you're better equipped to deliver a high-quality product that meets both functional and non-functional expectations.

In my over ten years of experience in tech leadership, I've observed that the most prevalent mistake is the excessive reliance on unit testing, particularly among junior developers. While unit tests are straightforward to develop and seemingly enhance the metric of test coverage, their practical benefits are often limited to specific scenarios, such as complex calculations. In many cases, particularly for CRUD-based APIs where the logic primarily involves data access and delegation, unit testing can be relatively ineffective. This is because unit tests are heavily dependent on the underlying logic, which, in the case of many data-driven APIs, resides predominantly at the database layer.

Furthermore, the mention of using a tool like Postman implies the need for automated API testing. Postman is a popular tool for API testing that allows developers to send requests to APIs and receive responses. By utilizing such tools, one can detect errors in the underlying codebase of the product, which may not be evident through manual testing of the user interface alone. This holistic approach, combining manual UI testing and automated API testing, helps ensure a more comprehensive and reliable regression testing process.

Selenium with tools like Xray in the Jira system is hands down my favourite way to track my UI and API testing. Great for reporting and easy to script. I agree sometimes you need different ways of testing. When I do load tests I use free tools like JMeter. A quick google will provide step by step instructions for setting up a JMeter environment, but it is simple to do. I actually often have a bunch of environments ready to go in the way of virtual machines.

Testing comes down to a multi layer approch and should include api monitoring of both non prod and prod workloads. Because you only know what you know. Plus adding security testing early on in your process (shifting left) is crucial to provide secure access and abstraction of your workload.

Test automation is key especially for complex API workflows because they are impractical to do by hand. These are the capabilities you should expect from your test automation tool. 1) API chaining - extracting data from a response and passing it to the next request should be easy. 2) Readable Tests and HTML Reports - you should be able to read a test-script top-to-bottom like a "user story" 3) Environment Switching - being able to switch URLs and secrets just by configuration. 4) Assertions - calling APIs and checking for a 200 OK is not enough, you have to validate the data returned. 5) Debug - Long workflows means that being able to step-through and debug an API test is important.

GitHub and Jenkins provides everything you need to automate. Reporting I like to use Xray and JIRA as it is easy and inexpensive. If you are using JIRA cloud, you can make it cheaper by isolating your testing team in their own environment from the rest of the company. There are some techniques that can be used to bridge the development JIRA and testing JIRA accounts to make it more seemless, but still save a bit of money.

When executing API tests in a CI/CD pipeline, it's crucial to replicate the production environment as closely as possible. For container-based applications, utilizing Docker is the most effective method to achieve this. In the case of serverless applications, consider deploying the app to its final cloud environment and conducting tests against an actual deployment. This approach ensures a more accurate reflection of how the application will perform in production.

Testing APIs with complex workflows like e-commerce or financial systems can be challenging. One approach is to use a tool like Postman or cURL to send HTTP requests and inspect responses. You can also use a testing framework like JUnit or Pytest to write automated tests. Another option is to use a commercial API testing tool like API Fortress or Mocky. These tools allow you to create test cases, simulate workflows, and validate responses. You can also use Docker to create isolated environments for testing. Additionally, you can use monitoring and logging tools to track API performance and identify issues.

Generally speaking, you almost always win to using automated testing. This is especially true when you have complex workflows with intricate permutations. Tooling is great but if your architecture doesn't support it, you're in for a bumpy ride. To leverage tooling, you need to be sure that the API can be decoupled from the production environment. All references to external resources need to be abstracted. This is done using interfaces and dependency injection to allow test suites to "plug in" to your system. Without this, you will need to create test environments, preload and sanitization schedules, and orchestration with anyone else using the environment. Be sure to plan ahead to fully leverage test automation and monitoring tools.

Tests should be an integral component of the code review process, alongside the actual implementation. It's essential to ensure comprehensive testing, covering not only the 'happy path' but also error codes, exceptions, and other edge cases. Adopting Behavior-Driven Development (BDD) style testing can greatly facilitate the reviewer's task. Moreover, aligning BDD descriptions with acceptance criteria can help verify that all implementation aspects have been thoroughly addressed.

Mocking and Simulation: Use mock servers or simulated environments to replicate dependencies that might not be readily available for testing. By following these steps, you can systematically test APIs with complex workflows, ensuring they meet functional, performance, security, and compliance standards.

Typically for testing I am suggesting to adopt testing pyramids, there are many different approaches, how to do that, one is quite well described in Martin Fowler blog, which often referencing. Having a clear contract for API and test coverage for API contracts before implementing something simplifies long-term maintenance and prevents quality regression during to backward compatibility issue. Also I am encouraging to learn about backward/forward compatibility to lose coupling between API, which essentially for complex flows. Also it is not always possible, however designing to avoid circular dependencies between API also could lead to more maintainable design.