Gradle task usage

I’m working on creating some UI tests with Masquerade. The only way, that I’ve found at least, to test the contents of tables is to add to the init scripts that run at database creation, which I’ve done. This way I know exactly the records that exist in the database and can check for them. My UI tests essentially take a record created through the init script and walks it through the entire process. But once it is walked through the process, I can’t run that UI test again because the expected record won’t be found at the starting point of the process. So I’ve found myself needing to create the database over and over.

In pursuit of ever more painless UI testing, I am trying to write a script (.bat) that will shutdown the application server ( a local tomcat install, the same that is created using setupTomcat) if running, creates a new database, starts the application server, and then jumps into my tests. My issue is that I don’t think I know the correct Gradle tasks to use. I’ve tried using the stop task but it doesn’t appear to shutdown the application server.

So, what is the syntax of how to use Gradle and what is the sequence of tasks that need to be run?

I should note that I already have a script to run the tests as described in the Masquerade docs. I’m just working on building on it to create the database when I run it.

I am using 6.10.13

Hello @wwnjj13

If you’re running tests in CUBA based project you can use createDb task to initialize database.

I can’t run that UI test again because the expected record won’t be found at the starting point of the process.

If you have to change data while tests are going, you should modify DB before test and perform cleanup after test ended.

I’ve tried using the stop task but it doesn’t appear to shutdown the application server.

Usually this task stops application server. Something is probably stopping this.

Would it be something of the form “gradlew stop createDb deploy start”?

hi,

I think there are more ways to accomplish setting up test data in your application on a per-test-case basis.

Alternative approaches to do test data setup for functional tests are (sort order: from white / grey to black box tests):

  1. connecting to the target database directly from the test class and setup the DB before test execution
  2. use special testing APIs of the application, that injects test data
  3. use general APIs of the application to setup data through the API
  4. use the user interface (with the selenium functionalities) of the application to setup test data

Where the extremes of this lists (either very “white” box and very “black” box tests) cause certain problems, the ones in the middle are normally suitable for regular cases.

In Masquarade there is the ability to use the connector functionality. I just skimmed through the README, but it is not very well documented. Basically it gives you abilities to from within the test case interact with e.g. the REST API or also with JMX beans directly. Here is one example of it:

In this regard the solution would be somewhere in between solution 2. and 3.

In general maintaining functional tests like UI tests is quite hard by the very fact that the tests are high level and that they are using the UI. In order to make it not even more hard to maintain one good idea is to keep the test data setup as close as possible to the actual test case.

This is why the Connector solution from masquarade is quite good, because it exactly allows to do that.

One valid alternative that you might want to leverage as part of your quality assurance of the software is the recently (7.1) introduced web integration tests.

Those test don’t have the dependency of selenium and the associated problems that come with it. Instead they spin up the web context of the CUBA application and then a lot of cases can be tested through that environment.

You can read more about it here: Web Integration Tests - CUBA Platform. Developer’s Manual

Cheers
Mario

1 Like