This was a data autogenerator for an API, initially supporting creating test users for local testing, utilised within the context of an initial MVP for adding automated tests to a system which had very little automated testing working - basically a test more akin to basic monitoring, and retroactively starting to add tests to a system that did not have them.
Users and auto payload detection (currently supporting user and agent creation on the API it utilised) was used for locally testing for critical bugs in the system, with the intention of integrating it into the deployment pipeline as a sense-checking first phase of testing (to make sure it didn't break or interfere with anything else) before it underwent more robust testing.
- A auto-payload generator script which detects and generate the payloads of several supported API calls
- A fixture which applies this for the purposes of creating end users and agent users on the tested API (which is not shared)
- A single test suite with fixtures fixtures to test this at different levels of user permission and reject if users should be unable to perform create/view actions on end users.
The auto-generated users would be used in testing other test suites requiring a new (and if needed, randomised) user. The auto detection/generation of payloads functionality would be customised with validation fields to then be used on general API testing where adaptive payload generation and potentially randomisation were required.
- Auto-generation of test end users on the fly which meet validation requirements, in order to add automated testing to the system which did not currently have maintained automated tests
- Going forward: Automatic detection of model changes to required fields which would enable core tests (when they were added) to continue functioning with little maintenance instead of tests heavily reliant on explicitly defined data
- The ability to in future easily extend this to automatically creating test users with RANDOMIZED data and richer validation data field support once non-latin alphabets were supported
- The ability to very easily generate test data at scale, eg populating a database for load testing, or testing a variety of scenarios, with the easy option to make this data randomized as well
- generating user data at scale
- automated testing using this user generator as a basis
- automated payload detection for less maintainability
- eventually randomised data and full payload detection for comprehensive automated testing on original data
- generate randomised data on automatically detected payloads (randomised fully automatic testing)
- load testing
- In terms of "randomizing" data
-
currently the ONLY the fields requiring validation are randomised, utilising an external API user generator.
-
fields which do not require validation currently use hardcoded values by design NOT randomised:
-
-
uniformity of fields such as "name" made it easy to distinguish auto-generated data for easy scripting of a removal script for all auto-generated test data on the local system as this was a this was initially a local tool for developers to be implemented on a local dev environment alongside developer-created data as a workaround to the absence of automated test environments
-
It also made autogenerated test data uniform and easier to distinguish visibly from custom-created data (as it was at this early stage primarily used as a local dev/test tool) through using the flag "autotest" wherever possible
-
This visibility was a benefit as we were not actually testing the impact of validated or randomised data at this stage in time as that would be a larger undertaking on the API being tested as it did not support the level of validation we would be testing through randomised users - eg only latin characters were supported and international numbers were not being handled correctly by the system, and with the intention of being able to auto-generate payloads and test data at scale, and potentially randomise it.
-
The primary immediate need was ability to create test users on the fly, and creating an auto-generator facilitated this
-
The long term goal in terms of users was potentially create data at scale in the near future
-
The scalability/maintenance/comprehensive testing goal was to eventually allow randomisation of data on automatically detected payloads
-
This was utilised locally by end users as a way to quickly
- test on a new user
- create end users meeting validation requirements
-
The actual need was for creating new user accounts every time which passed the validation requirements for a cellphone number and email address, which could then be used in follow up tests, and for scalably testing model changes with data not explicitly defined.
- Although this was running in the environment it was created in it is currently not set up to run - this currently set up for code styling demonstration purposes and variables/urls/etc have modified from the original context to avoid exposing any context the original script and suite was testing for security and proprietary reasons of the API this was testing.
This test suite I set up was run in a test environment only and with several constraints in less than optimal dev conditions (ie no automated testing/deployment/environments and utilising python 2.7) which I did not agree with, and which had several known bugs in it which the testing had to work around (hence all the Todos) and some of which this project in fact is part of the first steps in rectifying. The extensive commenting hopefully makes this clear.
This is an MVP which does currently not apply actual randomisation (though it can be easily added in one line) and the payload detection only detects simple supported API calls at this point in time from the system - this is the very first stage I employed in applying automation of testing capabilities and data reproducibility to a non-automated environment.
As echoed previously - this is not configured to run as it is dependent on an API which not publicly available therefore all references to the actual API/context which it was initially set up to run against and test are not included. This project is at this stage purely for code styling/writing demonstration purposes.