Test Process

This page documents the steps that a CAS developer/contributor should take for testing a CAS server deployment during development. For additional instructions and guidance on the general build process, please see this page.

Contributions

Patches submitted to the CAS codebase in form of pull requests must pass all automated unit or integration tests, and/or provide adequate unit or integration tests for the proposed changes. In the absence of appropriate test cases, the contribution most likely will not be accepted into the codebase and ultimately may be closed.

Testing Modules

To test the functionality provided by a given CAS module, execute the following steps:

For the tomcat, undertow or jetty webapp, add the module reference to the webapp.gradle build script of web application you intend to run:

implementation project(":support:cas-server-support-modulename")

Alternatively, pass the required modules automatically:

bc ldap,x509

…where bc is an alias for building CAS.

Prepare the embedded container, to run and deploy the web application.

Unit / Integration Testing

To simplify the test execution process, you may take advantage of the testcas.sh script found at the root of the repository as such:

# chmod +x ./testcas.sh
./testcas.sh --category <category> [--test <test-class>] [--debug] [--with-coverage]

To learn more about the script, use:

./testcas.sh --help

All unit and integration tests are executed by the continuous integration system.

Code Coverage & Metrics

Code coverage metrics are collected and reported by the following platforms:

System	Badge
Codacy
SonarCloud
CodeCov

Quality metrics are collected and reported by the following platforms:

System	Badge
Codacy
SonarCloud Quality Gate
SonarCloud Maintainability

Browser & Functional Testing

Automated browser testing is done via the Puppeteer framework. Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the DevTools Protocol and runs headless by default.

Functional tests start by generating a plain CAS overlay as a baseline that is able to run under HTTPS using a pre-generated keystore. This overlay is supplied the test scenario configuration that explains the required modules, properties, etc to use when CAS is deployed inside an embedded Apache Tomcat container. Once running, the Puppeteer script is executed by Node for the given test scenario to verify specific functionality such as successful logins, generation of tickets, etc.

All functional and browser tests are executed by the continuous integration system.

To install Puppeteer once:

npm i -g puppeteer

To help simplify the testing process, you may use the following bash function in your ~/.profile:

function pupcas() {
  scenario=$1
  cd /path/to/cas 
  ./ci/tests/puppeteer/run.sh ./ci/tests/puppeteer/scenarios/"${scenario}"
}

…which can later be invoked as:

pupcas <scenario-name>

To see the list of available test scenarios:

./gradlew --build-cache --configure-on-demand --no-daemon -q puppeteerScenarios

Remote debugging is available on port 5000. To successfully run tests, you need to make sure jq is installed.

To allow the firewall to accept incoming network connections for Chromium on MacOS, you may apply the following command:

chromium="/path/to/cas/ci/tests/puppeteer/node_modules/puppeteer/.local-chromium"
sudo codesign --force --deep --sign - "${chromium}/mac-*/chrome-mac/Chromium.app"

Continuous Integration