APEX e2e Testing Automation with Jest & Puppeteer #4
We dealt with iFrames and Jest’s global methods previously. As we conclude the series on front-end tests automation in Oracle APEX, this post is going to be mainly about organizing your tests by breaking them down in separate files and globally configure our environment.
The way I thought to be the optimal way to organize tests would be to group them according to the pages we find in the navigation menu. But before that we need to be able to write tests in such a way that we open a browser, log-in (exit if not successful), run tests in separate files, then close the browser instance once done.
Global Setup & Tear-down
Breaking down tests in different files will cause Jest to execute them independently. But what if we want to share some sort of global state across all test files? Specific to Oracle APEX, we need to make sure we logged in successfully in the application before executing any test and exit (consequently not executing any tests) if it’s not the case.
We’re going to make use of Jest’s “Global Setup & Tear-down” to efficiently “initialize”, as it were, our environment and gracefully exit once the tests finish. The idea behind is to:
- Call Puppeteer to launch a browser instance and log into the application
- If the login fails, throw an error, and exit
- If the login succeeds, use the file system node module to write the web-socket endpoint together with the homepage URL in a file(as exemplified here by the Jest People).
- Build the test Environment by reading the previously generated file, attach puppeteer to an existing browser-instance using the connect method and set couple of global variables that we’re going to need across all tests (like the homepage URL, the page browser instance and the homepage instance.
- Now, Jest will run tests using the above and after all tests are complete, the global tear-down config will be called to close the browser instance that all tests are using and thereby close.
To put this into perspective, this is how our directory will look like:
The config file jest.config.js is where we put the global configuration for our project. It is fairly simple:
It is only in env.js that global variables that can be accessed in test files will be set. Variables defined in globalSetup will only be available to be read in globalTeardown, as documented here.
What we do in our testEnvironment, among other things, we will read the file generated in the globalSetup extract the web socket endpoint (wsEndpoint) and set some global variables, like below:
With this set, I can easily now write a separate test file to redirect from the homepage to the “Orders” page and evaluate that with below code:
Now, I can break-down tests in separate files, using one browser instance, and, particular to APEX, one session. As you saw in the screenshot above, tests have their own directory, and each app has its own sub-directory where I’ll write down tests. Expanding the directory will give me this:
Maybe there’s a better way to organize your folder, but I find this organization and naming convention to suit me, because having files arranged and named like this makes easier to write a testSequencer, if I need to configure jest to run using some sort of sequence.
Now if I run the tests, this is the report I will get. Note that this is the verbose option switched on in jest.config.js
It’s now shown that the setting up of the environment ran first and passed the URL successfully to my test suites.
Please feel free to inspect this whole example over here at my github. Welcome for any input…
