Prior to the introduction of version control, API Fortress tests were stored only on the platform itself. In order to edit them, a user needed log in to the platform and leverage either the visual composer or the code view. When major version changes occured in the source code, tests would have to be manually edited to comply with the new schema. Testing new code against old schema isn’t a productive use of time, after all. As a consequence of this, small changes to source code could require a user to make changes to the test itself. Over time, as more and more changes accumulate with the developing codebase, users of the platform could be required to make many changes to their tests.
The introduction of version control has changed this process dramatically. The first part of the new story was the introduction of importing and exporting functionality. Many of the platforms users know that the test code itself that exists underneath the visual composer is based on XML. This XML can be edited directly via the code view. Now, the XML files themselves can be downloaded from the platform to a users own machine. From there, the files can be opened in the IDE or code editor of their choice and modified. This is where the exciting part happens. Since we can pull code out of the platform and edit it on our own machines, we can also push that code to the associated Git repository, where it can be stored alongside the source code that it’s designed to test. Furthermore, the code can be pushed back into the API Fortress platform. After this point, API Fortress will track the version status of the API Fortress test code. The platform can also track instances of the same test on different Git branches.
Now, while developing the actual source code for their API, a developer can also write the tests that API Fortress will execute to test those endpoints. These tests can be stored in Git along with the source code and be iteratively updated over time. Once the endpoints go live in a staging or development environment and need to be tested by QA, the QA analyst responsible for testing said endpoints can execute the tests that were written alongside the source code. As the source code is updated, so too is the test code, allowing the QA analyst to focus on the actual act of testing rather than making minor corrections to the test code itself. In the scope of a CI/CD pipeline, scripts can be written to validate that the correct version or branch of a test is pulled prior to test execution, allowing a team to test multiple versions of software without having to write different tests for each version.
The version control integration from API Fortress has enhanced the ability of a developer to participate in the testing process substantially. Many developers prefer to work in their own environment, so the introduction of the ability to import and export tests has made the API Fortress workflow more accessible to them. Combined with the platforms ability to track Git versioning, the platform is now even more able to participate in the full scope of the software development lifecycle.
API Fortress was specifically built for today’s agile architectures. A collaborative platform that bridges the gap between development, QA and DevOps. By collaborating using the simple GUI, teams can work together to create a series of powerful API test in one place. Then those tests can be executed at every stage of the lifecycle, in particular as part of the CI/CD process. Using our webhooks or Jenkins plugin, you can automatically execute tests and get notified of issues before the code is published live. The platform works in the cloud or on-premises, giving you the flexibility to run test from any environment while still satisfying security protocols. Catch errors before your customers find them and release code with confidence.
For other related articles, please check out API Fortress’s blog, here.