Testing

Last modified by Vincent Massol on 2019/05/21 09:36

There are various types of tests and everyone has its own terminology. You'll find below the XWiki terminology and best practices related to testing.

Check the general development flow to understand better how testing fits in the larger picture.

Testing Strategy

Here's the general testing methodology used by the XWiki project:

  • Code committed must have associated automated tests. 
  • There are checks in the build (in the quality profile - executed automatically on the CI) to ensure that committed code:
    • do not reduce the total test coverage for that module
    • do not decrease the mutation score for that module. Note: We use mutation score as a metric to gauge the quality of our tests.
  • Developers run unit and functional tests on their machines daily and frequently.
  • Unit and functional tests are executed by the CI, at each commit.
  • Most automated functional tests are currently running in a single environment (HSQLDB/Jetty/Firefox). However, we've started to use Docked-based testing to test automatically using several configurations and are migrating more and more tests to that. There are jobs in XWiki's CI that execute tests in all configurations regularly (not at each commit though but as much as possible).
    • Manual tests are also executed at each release by dedicated contributors and they manually execute tests that are not covered by the automated tests.
  • Performance tests are executed manually several times per year (usually for LTS releases and sometimes for stable releases too).
  • Responsiveness tests (e.g. verify that XWiki displays fine on a Mobile) are currently executed manually from time to time by dedicated contributors.
  • Accessibility (WCAG) tests are performed automatically at each commit.
  • HTML5 validity tests are performed automatically at each commit.

Unit Testing

Java Unit Testing

See Java Unit Testing

JavaScript Unit Testing

  • These are tests that do not rely on the DOM, written as "behavioral specifications", using the Jasmine test framework.
  • In development mode, you can start the test runner process by running mvn jasmine:bdd in your command line. This will start a test runner at http://localhost:8234, that will run all tests in the src/test/javascript directory. Write your tests there and hit refresh to see the results directly in your browser.
  • For tests that need a DOM, see Functional Testing

Java Rendering Testing

We have a special framework for making it easy to write Rendering tests, see the Rendering Testing Framework

XAR Testing

See XAR Unit Testing

Functional Testing

A functional test requires a running XWiki instance.

Functional UI Testing

We now have 3 frameworks for running GUI tests:

  • One based on Docker (and using Selenium 3+). This is now the recommended framework to use for new tests.
  • One based on Selenium2/Webdriver which is now deprecated and shouldn't be used. We encourage committers to port tests written for it to Docker tests. Especially when committers bring modification to the old tests we encourage them to rewrite the tests as new Docker tests.
  • A last one based on Selenium1 which is also deprecated and shouldn't be used. We encourage committers to port tests written for it to Docker tests. Especially when committers bring modification to the old tests we encourage them to rewrite the tests as new Docker tests.

Docker-based Testing

This is currently the official way to write UI functional tests.

See DockerTesting.

Selenium2-based Framework

Using:

  • To debug a test simply start XWiki somewhere and then debug your JUnit tests as a normal JUnit test in your IDE.
    • Note that functional test Maven modules will create an XWiki instance in target/xwiki thanks to the execution of the XWiki Packager plugin, so it's simpler to start this XWiki instance when debugging.
  • In order to debug more easily flickering tests you can simply add the @Intermittent annotation on your test method and it'll be executed 100 times in a row (you can also specify @Intermittent(repetition=N)to repeat it N times). This is achieved thanks to the Tempus Fugit framework that we've integrated.
  • To run a specific test, pass the pattern property (it's a regex on the test class name) as in: mvn install -Dpattern=TestClass#testName (this will run the testName test from TestClass)
  • To run the tests on your own running instance (instead of letting Maven close your instance and start a fresh one), use -Dxwiki.test.verifyRunningXWikiAtStart=true. It could be useful to verify that you have not broken the tests on your instance before committing your changes.
  • By default the Firefox browser will be used but if you wish to run with another browser just pass the browser parameter as in:
    • Firefox (default): -Dbrowser=*firefox
    • Internet Explorer: -Dbrowser=*iexplore
    • Chrome: -Dbrowser=*chrome
    • PhantomJS: -Dbrowser=*phantomjs
  • You may reach a compatibility problem between the version of the browser and the version of Selenium.  For example, at the moment, Firefox 32.0 is required.  You may install it on your computer and refer to it with -Dwebdriver.firefox.bin="/path/to/your/firefox-32.0"
  • We check for pages that require Programming Rights automatically by bundling a Listener component that listens to the ScriptEvaluatingEvent event and that drops Programming Rights, in an effort to make the tests fail and so that the developer can notice he requires PR and fix that. In some cases where it's necessary, this can be disabled by setting the configuration < testProgrammingRights>false</testProgrammingRights> in the configuration of the Package Mojo, and/or by using a System Property to control where the check is performed, e.g. <xwikiPropertiesAdditionalProperties>test.prchecker.excludePattern=.*:XWiki\.XWikiPreferences</xwikiPropertiesAdditionalProperties>. Since XWiki 9.8RC1
  • If the xwiki.test.startXWiki system property is set to true then the test itself will start/stop XWiki. If set to false then it's then the responsibility of the build to start/stop XWiki. Useful when starting.stopping XWiki inside a Docker container handled by the Maven build for example. Since XWiki 10.0

Best practices

  • Tests are located in xwiki-platform inside the module that they are testing. Note that in the past we were putting functional tests in xwiki-platform-distribution/xwiki-platform-distribution-flavor/xwiki-platform-distribution-flavor-test but we have started to move them inside the specific modules they are testing.
  • Name the tests using <prefix>IT.java
  • Use a AllITs.java test suite to ensure that XWiki is started/stopped only once for all tests in the module:
    @RunWith(PageObjectSuite.class)
    public class AllITs
    {
    }
  • Use the maven-failsafe-plugin for functional UI tests:
    <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-failsafe-plugin</artifactId>
    </plugin>
  • Locate tests in src/test/java (i.e the default maven location for tests)
  • Tests should be written using the Page Objects Pattern:
  • Since functional tests take a long time to execute (XWiki to start, Browser to start, navigation, etc) it's important to write tests that execute as fast as possible. Here are some tips:
    • Write scenarios (i.e. write only a few test methods, even only one if you can so that you can have a single fixture) instead of a lot of individual tests as you'd do for unit tests.
    • Use getUtil() to perform quick actions that are not part of what you wish to test (i.e that are part of the test fixture). For example to create a page you need in your fixture, write:
      getUtil().createPage(...);
      instead of
      WikiEditPage wep = new WikiEditPage();
      wep.switchToEdit(SPACE_NAME, DOC_NAME);
      wep.setTitle(DOC_TITLE);
      wep.setContent(CONTENT);
      ViewPage vp = wep.clickSaveAndView();
    • Your Maven module for test may depend on a specific profile (as a best practice, you can use integration-tests).  Doing this, it will be built only when specifically asked with -Pintegration-tests (see below for an example of the pom.xml)
      <profiles>
       <profile>
         <id>integration-tests</id>
         <modules>
           <module>application-task-test</module>
         </modules>
       </profile>
      </profiles>
  • Never, ever, wait on a timer! Instead wait on elements.
  • If you need to create, update or delete a page during your tests, use a space name specific to your test scenario with getTestClassName(). For example:
    getUtil().createPage(getTestClassName(), "Page", "Content", "Title");
  • Tests must not depend on one another. In other words, it should be possible to execute tests in any order and running only one test class should work fine.
  • Tests that need to change existing configuration (e.g. change the default language, set specific rights, etc) must put back the configuration as it was. This is true only in flavor tests or when several functional tests of different domains are executed one after another. However functional tests located in xwiki-platform specific modules are only running the tests for their module and thus it's not important, and saves times, if they don't clean up.
  • Tests are allowed to create new documents and don't need to remove them at the end of the test.
  • Stdout/stderr validation errors

    We have a check that verifies if functional tests output some invalid content to stdout/stderr. If your test contains such errors it'll fail and then you have 3 options:

    • It's a normal and expected output from the test (for ex the test verifies an error condition and it's expected it will raise a stack trace in the console). In this case add an expectation in the test. For example:
      public class TemplateTest extends AbstractTest
      {
         public void wrongTemplate()
         {
             ...
             this.validateConsole.getLogCaptureConfiguration().registerExpected( "Possible break-in attempt!",
                 "Error getting resource [null]");
         }
      ...
    • It's a non-expected error. You then have 2 sub-choices:
      • Fix the problem (the best and recommended solution!)
      • Increase the technical debt by adding an exclude. For example:
        this.validateConsole.getLogCaptureConfiguration().registerExcludes(
           "java.lang.IllegalStateException: Response is committed");

Examples of functional tests:

Old Selenium1-based Framework

  • We were using Selenium RC to perform functional tests for GUI. We had created some JUnit extension to easily write Selenium tests in Java.
  • To run these tests on your local machine go to xwiki-enteprise/xwiki-enterprise-test/xwiki-enterprise-test-selenium and type mvn install.
  • To run a specific test, pass the pattern property as in: mvn install -Dpattern=DeletePageTest (this will run the DeletePageTest - Note that you don't have to specify the extension). In addition if you wish to execute only a specific method from a Test Case class, you can pass the patternMethod property as in: mvn install -Dpattern=DeletePageTest -DpatternMethod=testDeletePageCanDoRedirect.
  • To enable debug output from the selenium server start maven with the -Ddebug=true switch and then all messages from the selenium server are saved to: xwiki-enteprise/xwiki-enterprise-test/xwiki-enterprise-test-selenium/target/selenium/server.log.
  • To debug a functional Selenium test in your favourite Java IDE go in xwiki-enteprise/xwiki-enterprise-test/xwiki-enterprise-test-selenium and run maven with -Dmaven.surefire.debug. Maven will wait till you connect your IDE to the running JVM on port 5005. You can put a breakpoint in your IDE and debug the test.

Browser version

Currently we only run our functional tests on the Firefox browser.
The browser you use for functional tests needs to match the selenium version, otherwise unpredictable results may occur.

  • The current Selenium version we are using is 2.44.0
    • (valid for 18.March.2015. Actual version used can be verified here under the selenium.version property)
  • The Firefox version we use in you continuous integration agents is 32.0.1.
    • (valid for 18.March.2015. Ask on the list or on IRC for the actual used version since it's not publicly verifiable) 
    • To determine browser compatibility with the Selenium version used, scan Selenium's changelog and look for entries like "* Updating Native events to support Firefox 24, 31, 32 and 33". That shows the supported browser version for the particular Selenium version.

If you wish to run tests with the exact configuration as XWiki's Continous Integration server uses, you need to install and use locally the same Firefox version. To do so, you have to:

  1. Download the corresponding Firefox release
  2. Unzip it locally
  3. Use the webdriver.firefox.bin java system property to specify the location of your firefox version
    1. Depending on how you are starting the functional tests, you`d have to either add the system property in your maven build (surefire plugin configuration) or in your IDE (run configuration)
    2. Read Selenium's FirefoxDriver documentation for more information and options

XHTML, CSS & WCAG Validations

Performance Testing

  • These are memory leakage tests, load tests and speed of execution tests.
  • They are performed manually and in an ad hoc fashion for now. They are executed for some stable versions and for all super stable versions.
  • See Methodology and reports.

See the Profiling topic for details on how to use a profiler for detecting performance issues.

Manual testing

Here's the spirit we'd like to have from the XWiki Manual Testing Team: The Black Team.

Besides automated testing, ensuring software quality requires that features be tested by actual users (see Manual testing). In order to manage manual testing, a test plan is required. 

Tools Reference

We use the following tools in our automated tests:

  • JUnit: test framework
  • Mockito: mocking environment of unit test to isolate it
  • Hamcrest: extra assertions beyond what JUnit provides
  • GreenMail: for testing email sending
  • WireMock: for simulating HTTP connections to remote servers
  • Selenium: for functional UI test to simulate a user interacting with XWiki
  • TestContainers: Docker-based functional testing
  • JMeter: for performance tests
  • Dumbbench: for manual performance tests

Test Coverage

See the TestCoverage page.

Mutation Testing

We use PIT/Descartes.

You can generate a report for the current module by running: 

mvn clean install -Pquality -Dxwiki.pitest.skip=false -Djacoco.skip=true

This will generate 2 reports:

  • The PIT one in the target/pit-reports/<timestamp> directory
  • The Descartes one, showing the Pseudo Tested and Partially Tested code, which are good indicators of what needs to be fixed, in the target/pit-reports/<timestamp>/issues directory
Tags:
Created by Vincent Massol on 2018/11/25 11:24
   

Get Connected