- Is your application easy to understand and use, even by those with a disability?
- Does your application need to work across various different browsers and devices?
- Does your application need to work in multinational and/or international environments?
- How will your application perform when subjected to unexpected production loads?
- How can you ensure your application is safe from security-related vulnerabilities?
Unit testing
The objective of unit testing is to test individual units of code. If you create custom code within Auth0 in the form of Rules, Hooks, and/or Custom DB scripts, you should consider use a testing framework (such as Mocha) to test your code. Companies who have been most successful with Auth0 have found it useful to execute these unit tests prior to automatically deploying Auth0 tenant configuration and collateral.Integration testing
It is a recommended best practice that you set up different tenants for development, testing, and production as discussed in Architecture guidance for SDLC support. Auth0 allows you to configure variables that are available from within custom extensibility; these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:- For use of variables in Rules, see how to configure values
- For use of variables in Hooks, see how to configure secrets in the editor
- For use of variables in Actions, see Explore Flows and Triggers
- For use of variables in Custom DB Scripts, see the configuration parameters