• How to set secure test data

  If you want to pass sensitive test data like passwords to the test runner, use DATASETs to setup secret test data instead of writing it into your test script. Secret test data will only be known to you, and will be masked in the test reports. Here's an example, using this test to sign up for GitHub: Use DATA. variables for the access credentials which we want to replace using the datasetsSome readers

• How to RUN or REUSE test scripts from another test script

  Using the TEST.run() command will allow the user to RUN or REUSE the test script in another test script. Why should you use TEST.run command? Using the TEST.run command will allow the user to use 1 test on multiple or different test scripts, this will greatly help the user to have a more efficient way of testing and editing the test. Sample: A Login module that will be used in multiple cases or in different cases. Instead of creating a login module in each individual test scSome readers

• Running test through a regional proxy

  To run a test in a particular region, click on the gear icon besides the run tab From there, you can select additional regions to run your test A similar drop down exists in the monitoring tab, for scheduling of jobs. This will also configure the time zone to the respective region 😉 The full list in textSome readers

• Can UI-licious solve ReCaptcha puzzles?

  UI-licious cannot solve ReCaptcha puzzles. ReCaptcha is designed to differentiate bots from humans with puzzles that humans can solve easily but bots can't. If you need to test a website that has ReCaptcha, you should setup a test environment where ReCaptcha is disabled, and run your tests on the test environment instead.Some readers

• How do I test with external login providers

  For production applications with production accounts This is typically acceptable for low testing loads (like 1 to 3 a day). However as with most automation. Eventually reCAPTCHA will be triggered. For most login providers, uilicious is considered a "bot" from the login provider point of view. And will be treated as such. While there might be ways to do so in the black market, we do not support such practises. Hence, we would instead recommend the following options, for testing with extSome readers

• Testing localhost applications

  Uilicious needs a public url to test your application. You can use a free service like ngrok (or similar alternatives) which will temporarily expose your application to a public url with a secure tunnel. Installing ngrok: Open the command prompt or terminal, and run the following to install ngrok. Running ngrok: If your application runs on port 3000, run the following to start ngrok. (https://storage.crFew readers

• UI-licious Static IP Addresses

  If you want to filter traffic from the UI-licious test servers (e.g. to disabling Sign In 2FA, or to exclude UI-licious traffic from analytics), you can refer to this link for the ip list: https://docs.uilicious.com/v3/reference/configurations/cloud-ip-list.htmluilicious-cloud-ip-listFew readers

• How should production credit card details be handled in Uilicious tests?

  All payment providers, including stripe. Strongly recommends the usage of test credit cards in testing environment. You can find details for stripe here - and this is for good reason. Even if Uilicious platform, and team is perfectly secure, from external threats. You will have to consider the security of everyone on your team who has access to the reports. Credit cards are typically not masked from screenshots, and as such, would be clearly visible to all members who has access to your UilFew readers