Advanced Suitestify settings

Suitestify can automatically instrument your HTML-based application and offers many additional useful tools for your testing and debugging.


Suitestify proxies your app's resources through a temporary address while inspecting and modifying them in real time.

Consider an app that runs under app.example.com. When running your test with a configuration that uses Suitestify, instead of opening the real app's address, Suitest sends the device to a temporary domain (something like a94fee3.suite.st) that mirrors the origin domain app.example.com.

Suitestify fetches resources from origin domain while on the fly translating other URLs found in the sources of your app. A separate temporary domain is created for every domain that your application uses.

Automatic discovery of new app domains

Your app may spread over multiple domains and you may not even be aware of it. Suitestify can help you discover all domains that are used in your application.

To enable discovery check the Try to find new domains during testing check box. Then, when you use the app, Suitestify will keep track of the domain names it finds in the app's resources. It will list the domains inside the Found domains field.

There usually will be a lot of false positives, that's why you should review the search results periodically and move valid domain names to the configuration field above and the invalid ones to the Ignored strings(false positives) field.

Side effects of Suitestify

If your app relies on the origin domain, it's "suitestified" version may not work as expected since it will be running on a random domain each time.

In this case you should create one or more Code overrides to patch up the problematic spots in code. Fixing such problems may require deeper technical knowledge. You should be careful not to change the app's behavior with code overrides, when in doubt consult with the app's developer.

Advanced Suitestify features

Server response manipulation

To create a particular test case it is often required to manipulate the response of a certain URL. Suitestify can automatically "freeze" contents of an URL or map the request to another URL based on the rules defined by you in this configuration.

Freezing the server response

To set up data freeze for a particular URL define a rule that would match this URL and then run the app through Suitest. The first time your app calls the matching URL, Suitestify will cache the server response and return the same response for all subsequent requests.

The cached URLs can be viewed and managed on the app configuration page. The cache never expires but you can delete the cache for a particular URL.

Data freezing options
Data freezing options

Mapping the request to another URL

Sometimes it is more practical to replace the response with the contents of another URL. For example if you have a local server serving mock data you can have the app fetch data from this server without actually changing the app itself.

Mapping is a powerful way to simulate a state when a server delivers a very particular response or no response at all. For example you can simulate the case when the server is down or some URLs send incorrect responses in order to test if your app behaves gracefully in such cases.

Mapping
Mapping

Using wildcards in the matching rules

When specifying the URL matching rules you can have a rule matching several requests by using a wildcard. For example http://myapi.com/*/list would match (and the corresponding rule would be triggered for) all of the following requests:

  • http://myapi.com/pictures/list
  • http://myapi.com/videos/list
  • http://myapi.com/a/b/c/d/list

Busting the cache busters

Sometimes the business logic requires the application to always request a unique resource by appending a so-called cache buster string to the URL. An example of such URL is http://myapi.com/pictures/list?t=2325235232 where the value of the parameter t is always a different and random one. Caching every such URL would not make sense since that request will never be repeated.

You can instruct Suitestify to ignore the cache buster string for the purposes of caching. Use ** in place of the cache buster string. For example, the following rule: http://myapi.com/pictures/list?t=** will match these URLs

  • http://myapi.com/pictures/list?t=3325235232
  • http://myapi.com/pictures/list?t=4234234234
  • http://myapi.com/pictures/list?t=ad3

and it will have a single cache version for all of the above requests.

Manipulating app source files

Sometimes it is practical to augment the app a bit to force a particular state or get rid of part of the logic in order to more easily test the other part.

The Code overrides feature of Suitestify allows you to replace parts of app's code on the fly. The code overrides apply to the app configuration and you can have as many of them as necessary.

Configure code overrides
Configure code overrides

Consider the following example: The app's home page changes layout based on the time of the day, in the morning it shows a listing and during the prime time it shows a big teaser instead. As a tester you need to cover both cases with tests as well as create a test verifying that the business logic driving this change is correct.

It is certainly impractical to wait with launching your tests until the specific hour you need a way to force the particular state of the app at any time.

Assuming that the app contains logic like this:

switch (new Date().getHours()) {
    case 20:
        setAppLayout('primetime');
        break;
    default:
        setAppLayout('listings');
        break
}

You can define a code replacement rule replacing the switch above with a simple setAppLayout('primetime'). When you run the app with a configuration containing this override the app will always display the primetime layout which is very convenient for testing this case. You can then force another app state in another configuration.

If your app depends on the origin domain name you may need to apply one or more code overrides in order to make the "suitestified" version of it work as expected.

Consider the following example:

var location = window.location.host;

if (location.startsWith('staging.')) {
  launchMyApp(location);
}

Obviously, the if condition above will never be fulfilled since Suitestify has fed the device with a temporary URL. For the app to work, we have to get rid of that if and replace it with launchMyApp('staging.example.com');

Suitestify code override example
Suitestify code override example

Be sure to replace the smallest amount of code necessary in order to not to alter the application's behavior. Also make sure you keep all the spaces and formatting in the code exactly like in the source file. Suitest performs a simple string to string replacement here, so the spacing is important.

Proxy server

To avoid blocking of Suitestify you can either whitelist its IP or provide Suitestify with a proxy server (which prevents issues with geo-blocking / filtering policies). Suitestify IP can be found in settings page of your application.

One of the common uses is to access applications from other countries to get the local content or behavior. For example, you can use this to test if the correct content is displayed for different countries.

You should specify your proxies following these rules:

  • Domain name is mandatory, for example https://my.proxy.server. Make sure to include either http or https based on protocol used.

  • Optionally you can include the password, username and port with the domain name. For example, https://password:username@domain.name:8080.

Suitestify limitations

Suitestify will not process files bigger than 10 MB. The file will still be delivered to the application but code overrides and other changes will not be made.