Your application is started locally. Now we will test this feature by updating your code. Update the worker/index.ts file as following:

Save the file and check your terminal. You should see something like this:

You can check that the code is really updated by clicking on the 'hello' button. Now you see that "Hello World !!!" is displayed in the web page.

To demonstrate a change in your front, we will update the code of the saySeveralTimes function:

Save your file and reload your web page. Enter a message ("hello" for example) and click on 'say something' button. You should see "hello - hello - " (if you have chosen 2 repetitions).

As your application grows, you will need to use other built-in cloud services or custom cloud services.

We will improve our custom cloud service to use the Stack built-in cloud service to store messages. First Stack service is provided by @zetapush/platform-legacy module. So you have to install it. You can keep your application running in your terminal and open another terminal in the same folder. Execute this command in the new terminal:

You can now import Stack service in your code and use it:

You can save your file and if you look in your terminal, you can see something like this:

To ensure that everything works fine, you need to update your front:

Save your file and reload your web page. You can enter a message ("foo" for example) and a number of repetitions (5 for example). Then hit the 'say something' button. Now you will see something like:

{"message":"foo - ","times":5,"fullMessage":"foo - foo - foo - foo - foo - "}

This means that your custom cloud service has been reloaded and the Stack service is really used. You can ensure that by reloading the web page, you will see the message displayed in the web page.

Unit testing is a great way to provide quickly a feature without losing time on going back to the right execution context. The component (or class here) is tested alone (all dependencies are mocked).

This section shows that you don’t need ZetaPush for unit testing and that you can use any testing library you want. For the example, we use jasmine because in addition to testing tools, it also provides basic mocking features. For the example, we will reuse our HelloWorldAsCustomCloudService and we will improve it.

As a reminder, here is the complete code of the custom cloud service and front:

Firstly, we add jasmine by running:

We want to test saySomething cloud function to ensure that the generated message corresponds to what we really want. Let’s start by writing the skeleton of the tests. Create the file spec/hello-world-custom-cloud-service/say-something.spec.js with the following content:

We have prepared the tests and the expectations. Now we need to instantiate the HelloWorldCustomCloudService for testing it. However this function has a dependency to the Stack built-in cloud service. So normally, to test it we need the ZetaPush worker and the ZetaPush cloud to instantiate this service. But in unit testing, we mock all dependencies to test only HelloWorldCustomCloudService:

Now our cloud service is ready to be tested. We can run jasmine but as the custom cloud service is written in TypeScript, we need to run jasmine with ts-node:

If you run the tests, you will see that only one test succeeds. This is normal because if you look closely at the tests, you can see that the expected behavior is to have no new line at the end of the string. So the code of the custom cloud service doesn’t match the expected behavior. Let’s fix the code of the cloud function:

Now if you run again the tests, you can see that 4 tests are succeeding and only 1 left in failure. The test in failure is normal because we expect a particular message if times parameter is not a number. We can fix it by updating the code of the cloud function like this:

Now you can run again the tests and everything is ok. You can notice that running unit tests allows to develop faster because you just need to run everything at once instead of entering messages and number of repeats manually in your web browser several times.

Testing a custom cloud service alone is good but you often need to tests interactions between several cloud services or interaction with built-in cloud services. ZetaPush provides tools to help you write integration tests and to setup a ZetaPush context for your tests.

First, you need to install the @zetapush/testing module:

Then, as done before we will write the skeleton of the tests. Create a new test file spec/hellp-world-custom-cloud-service/say-something.it.spec.js with the following content:

We have defined what we need to test. Now to make it work, we need to run the test in a ZetaPush worker. As a reminder, using ZetaPush built-in cloud services requires a creation of the services on the ZetaPush cloud. As a reminder too, ZetaPush worker detects needed dependencies and instantiate them. In the context of a test, we also need these mechanisms in order to instantiate the dependencies and to inject them in our test.

ZetaPush testing module provides several utilities to define an execution context and to run the test in that context. Add the following code to your test:

Now you can run the test using jasmine too:

You can see that contrary to unit testing, the worker prepares the test context. You should see something like:

The following sequence diagram explains how it works:

Jasmine executes the code of the test and starts by running code of the beforeEach function. given() fluent API is called 1 but does nothing. In fact, given() is just the entry point to the fluent API. given().credentials(), given().project() and given().worker() only store information about what you need for your test 3 4 5 6 7 8. Nothing is initialized here. We don’t show all calls to the fluent API in the sequence diagram because it is the same principle, we just store information about what you need in your test. As all needed information is grabbed, you ask the testing utilities to prepare the context by calling apply(this) 9. The testing utilities prepare the context by asking to the worker to start your "virtual" module defined with testModule 10. The worker connects to the ZetaPush cloud using your credentials 11 12. As a reminder, we used given().credentials().fromZetarc() so it will use the credentials defined in the .zetarc file directly. Then the worker resolves all needed dependencies (for dependency injection) and for each built-in cloud service, it sends a message to the ZetaPush cloud to create the service 13 14. Once all built-in cloud services are ready, the worker instantiates all built-in cloud services and custom cloud services needed for the test (indicated by given().worker().dependencies()) 15 16 17 18. Once everything is instantiated, your custom cloud service is ready to be called. At the end of the apply function of the testing utilities, the information about the execution context (credentials, dependencies, instances, …​) are stored in this 19. this refers to the current test execution context in jasmine.

Now, everything is ready to really start the test. The it function provided by jasmine is executed. This function calls runInWorker(this, callback) 20. As said above, this refers to the current test execution context in jasmine. So everything stored in this in beforeEach is available in this of it. runInWorker starts the worker using the code written in the callback as source code for a "virtual" cloud function 21. The "virtual" cloud function (callback) receives parameters. Each parameter is the instance of a needed dependency (defined with given().worker().dependencies() in the same order). As it is like a real cloud function, the code is executed by the worker 22. Then each line of code is executed. In our test, we first empty the Stack by calling purge() 23 26. This sends a message to the ZetaPush cloud 24 25. The test then calls helloWorldService.saySomething('hello', 5) cloud function 27 28. helloWorldService.getStoredMessages() cloud function is called to retrieve all stored messages 29 30. At the end of the test we use expect function provided by jasmine in order to ensure that results correspond to what we expect.

The test is now finished (either successfully or with failure). afterEach is called by jasmine which calls autoclean(this) utility 31. As the worker has been started locally and it has instantiated dependencies, we need to clean everything. autoclean will use information stored in this to know exactly what it has to do. In our case, we just need to stop the worker properly 32 33 34 35.

Notice that local tests allow to test part of your application. You don’t need to develop all your custom cloud services before testing them partially. This is a great advantage for developing fast because you can define a closed and well defined context that doesn’t depend directly on the code you write in your custom cloud services. Maintainability is easier because even if your code change, the context dedicated to the test may be the same.

Here the tests are run exclusively in a worker context. ZetaPush also provides a way to write end-to-end (often named e2e) tests. This means that a client really make requests to the cloud service instead of calling directly a method.

You can copy the file .spec/hellp-world-custom-cloud-service/say-something.it.spec.js into the new file .spec/hellp-world-custom-cloud-service/say-something.e2e.spec.js and transform code to an e2e test:

As always, you run the tests by running jasmine:

Running the test may fail and it is normal because the Stack may already contain data. As said before here we are in the context of a client so we don’t have access to Stack service to empty it before running the test. To empty the Stack you have to either add a cloud function that can empty the stack or use ZetaPush snapshots to restore your application to a particular state before running your tests.

The following sequence diagram explains how it works:

Context initialization done by given() 1 utility has exactly the same behavior as integration testing. The only difference is that instead of creating a "virtual" module to define a "virtual" custom cloud service, given().project().currentProject() 2 3 indicates that you want directly the code of your application to be tested. given().worker().up() 4 5 indicates that you need the worker fully started before running the test.

it() code now uses front(this) 20 that is a fluent API to create a client based on what you need. front(this).name() 22 is used to add an information message in logs during test execution. It is useful if you want to separate several calls to simulate several end-users for example. Until now, no client is created. It is front(this).execute(callback) 24 that uses information defined before (name and current test context in this case) in order to create a client instance 26. The testing utilities connect the client to the ZetaPush cloud 27 28 using information provided in given().credentials(). In addition to a client, this function also creates the client API (api) 29 by calling client.createProxyTaskService under the hood. As a reminder, api created with client.createProxyTaskService provides directly same methods to the client that the cloud functions defined in the custom cloud service without writing a single line of code (no need to manually define a function saySomething on the client side). Once the client is ready, the code defined inside the callback is executed 30 31. In the test, the cloud function saySomething is called through api 32. Contrary to integration testing which calls cloud functions directly, calls to api sends messages through network from the client to the ZetaPush cloud 33. ZetaPush cloud routes the message to the worker started by testing utilities 34. The worker receives the request and calls the cloud function 35. The result is sent by the worker to the ZetaPush cloud 37 which routes the result to the client 38. The client receives the result and can use it 39. The same process applies when calling getStoredMessages() 40 41 42 43 44 45 46 47.

The autoclean(this) works exactly the same as in integration tests.