FOLIO integration test framework (UITEST-2)

[UITEST-5] Document how to write module tests to be included in regression test suite. Created: 25/Aug/17  Updated: 01/Sep/17  Resolved: 31/Aug/17

Status: Closed
Project: stripes-testing
Components: None
Affects versions: None
Fix versions: None
Parent: FOLIO integration test framework

Type: Sub-task Priority: P3
Reporter: Niels Erik Nielsen Assignee: Niels Erik Nielsen
Resolution: Done Votes: 0
Labels: demo21, sprint21
Remaining Estimate: Not Specified
Time Spent: 5 hours, 5 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to UITEST-6 Document how to run module tests from... Closed
relates to STRIPES-461 document ID/naming scheme Closed
Sprint:

 Description   

Where to put the tests in the module and how to use the test context that ui-testing provides to the module.



 Comments   
Comment by Niels Erik Nielsen [ 25/Aug/17 ]

Either documented in the contribution guide or linked to from there.

There are examples in ui-users, ui-items, ui-checkout and stubs in ui-requests, ui-checkin.

Comment by Niels Erik Nielsen [ 28/Aug/17 ]

For ui-testing to include a module's own tests in an overall test suite, the module should contain a folder ./test/ui-testing with the script test.js.

This script will receive one argument from ui-testing, a testing context. With that, the script can run Nightmare tests ( see https://github.com/segmentio/nightmare/blob/master/Readme.md ).

This is an example of the most minimal module test (it logs in and confirms that the app page opens):

 module.exports.test = function(uiTestCtx) {

  describe('Module test: app:minimal', function() {
    const { config, helpers: { login, openApp, logout }, meta: { testVersion } } = uiTestCtx;
    const nightmare = new Nightmare(config.nightmare);

    this.timeout(Number(config.test_timeout));

    describe('Login > Open module "Requests" > Logout', () => {
      before( done => {
        login(nightmare, config, done);  // logs in with the default admin credentials
      })
      after( done => {
        logout(nightmare, config, done);
      })
      it('should open module "Requests" and find version tag ', done => {
        nightmare
        .use(openApp(nightmare, config, done, 'requests', testVersion))
        .then(result => result )
      })
    })
  })
}

The main script test.js should probably just be a pointer to the actual tests, so that module developers can select exactly which tests to include in the overall ui-testing suite at any time:

const minimal = require('./minimal.js');
const extensive = require('./extensive.js');

module.exports.test = function(uiTestCtx) {
  minimal.test(uiTestCtx);
  extensive.test(uiTestCtx);
}

The individual tests can always be run directly from ui-testing around test.js, provided they are found in ./test/ui-testing.

The contents of the testing context argument are:

{
 config :  (see ui-testing/folio-ui.config.js)
 helpers: {  
   login:    function for logging in to the FOLIO app
   logout,
   openApp:   function for opening a module's page
   namegen:  function for generating user names and addresses 
 }
 meta:  {
   testVersion:  the npm version of the module that the test is pulled from
 }
}

Note: The test context is in its very first version and could be subject to change.

Comment by Niels Erik Nielsen [ 28/Aug/17 ]
Developing UI modules and writing tests.

Programmers developing UI modules are conventionally installing a Stripes platform, checking out their UI module from Github or similar, and yarn link'ing the local project into the platform.

To test the UI module as work progresses, ui-testing should be installed too and pointed to the Stripes web service serving the developing module, and the module's tests can be run as described elsewhere

This will suffice if the changes do not require test changes, for instance if it is a refactoring that is not supposed to change UI behavior.

On the other hand, if the changes to the UI module do require the tests to be updated as well, the UI module project should be yarn link'ed into both the Stripes platform and ui-testing.

When writing tests for an already submitted UI module, the project could be yarn link'ed into ui-testing only.

Comment by Jakub Skoczen [ 28/Aug/17 ]

David Crossley Mike Taylor Guys, let's decide where the above documentation should be incorporated (also UITEST-6 Closed , STRIPES-461 Closed ): dev.folio.org CONTRIBUTING guildelines or Stripes developer's guide.

Comment by Mike Taylor [ 29/Aug/17 ]

Seems to me like it belongs in https://github.com/folio-org/stripes-core/blob/master/doc/dev-guide.md – it's Stripes-specific, not something about being a FOLIO contributor in general. Agree, David Crossley?

Comment by Niels Erik Nielsen [ 29/Aug/17 ]

Right, Mike Taylor, David Crossley

The places I know of that already describe or refer to or touch on this:

ui-testing itself: https://github.com/folio-org/ui-testing/blob/master/README.md

The UI release procedure: https://github.com/folio-org/stripes-core/blob/master/doc/release-procedure.md#notes-on-testing

https://github.com/folio-org/stripes-core/blob/master/doc/dev-guide.md#unit-testing

http://dev.folio.org/community/contrib-code#automation

Comment by David Crossley [ 30/Aug/17 ]

In discussion with Niels Erik, we decided to put documentation in "ui-testing" README, and link to it from various places.

Comment by Mike Taylor [ 30/Aug/17 ]

OK, makes sense.

Generated at Thu Feb 08 23:08:27 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.