Watch the Video
Introduction
In this article, we are going to explain how to verify license activation and client/server interactions.
There are two levels of testing with Zentitle, the initial testing where we are checking that the components are working together - we did that in the previous step when adding the code to your application and we continue that here. Then there is advanced testing where we try various license use cases to ensure a real deployment will function as you are expecting.
Within a trial, the first test is useful to show how Zentitle works and to illustrate the basic functionality. The way Zentitle licensing works is to triangulate between your code, our library, and our licensing cloud (and license codes). So testing includes ensuring all those areas are communicating together effectively.
You may choose between cross-platform command-line testing, along with our tools for desktop, mobile, and ARM that save you having to code your own application while trying out Zentitle.
Gathering your resources
Before you get started on your testing you need to have gone through the previous steps in our getting started guide. You should now have ready in your test setup:
Your own licensing library. This library should match your test environment and bittage.
A test application (or your own app.) that has been edited to match the library settings (Customer/Product IDs and Constants).
The tool to delete the client-side records after each cycle (only desktop).
A Product Setup on the Publisher Center with license codes allocated for testing.
A set of Zentitle License Codes to test (that have been allocated to the test product).
How the test process works
Once you have all the resources together, the sample code projects (or your own code) that have been edited to match your library, the library in the same folder, and the test license codes you can start.
The test process is broken into two phases:
Test the base communications and licensing functions such as a trial "timeout", a successful "activation" and a "de-activation" of a perpetual license. This illustrates the application can communicate with the server and that the licensing is securing the application.
More advanced testing and the use of Analytics data. Here we test the various functions around features, User extensible licensing, and other license models such as subscription licensing. In addition, we can collect detailed end-user engineering and usage Analytics.
When testing you will go back and forth between the client and server UI. This is a simple and fast process of observation to check the various tests are showing the expected results.
Testing can be done within a platform-specific to your project, or you can use a simpler command-line tool that is cross-platform, allowing you to test really fast across Windows, Mac, and Linux devices. VMs will work fine for testing but we also suggest final testing on the real hardware to complete your QA cycle.
Watch the "clock"
A key area where confusion can occur in testing is the timing between events. As many of the tests are based on the "clock" i.e. timing of events such as trial period, subscription or end date at the client you need to be clear on what clocks are running where. For example, you will have a clock running on your local test device, what timezone is that set too (and is it set to the correct time?) and how does that compare the cloud-based server clocks that record time in CT? In Palo Alto, for example, we have a time difference between the local (PST) client clock and the Server clock (CT) and must consider that "time difference" when testing as the Server clock is the "control" clock.
In addition, the time set for calling back from the client to the server (the lease period/heartbeat) has an effect on testing. In order to avoid timing issues here i.e. a long time between calls and therefore out of date client license status, we always manually refresh the license on the client as we test to ensure that the license is updated in real-time. This is an extra step not found in the deployed state of the application.
Watch the "state"
During testing, you will also need to watch out for how the UI or license state presents itself as this can be confusing. In many cases where we use a tool to test and not your code, you will be manually hitting the servers, and as a result, the UI will often show the license state as "unlicensed" (-1) but what it really means is that you need to refresh the license status to get the details.
For example, when you start the process it will show as unlicensed on the client as you will have never contacted the server for that device and therefore it is unlicensed at this point - if you have a trial set up on the server then when the client first connects it will then switch in the local UI to show a trial state, away from unlicensed.
Also, in between testing sessions, there may be a need to contact the server to get the correct state before you start testing as we are not relying on the usual client -> server heartbeat but a manual process.
In short, remember to expect the license state to only be correct after you have refreshed it by calling the server on each test process or cycle.