This repo contains system tests for the ConDec Jira plugin. The tests run by sending HTTP requests to a Jira instance running the ConDec plugin. The tests aim to test the most important functionalities of the ConDec plugin.
To run these tests, you will need a recent version of node
(this was tested using node version 12) and npm
.
To get all dependencies of the repo, run
npm install
You will need to copy the file config-template.json
and name the copy
config.json
.
- In
config.json
you can change the settings to use a specific URL for Jira or a specific user. - If you are using Jira issue types with names in a language other than English, you can set the property "defaultIssueType" to an issue type name existing on your system. For German, a good value for this property is "Aufgabe", which corresponds to the type "Task", which is the standard task type for the default issue type scheme.
Do not push the config.json
file! It contains data local to your computer, which could be sensitive!
Checklist:
- (optional) run
atlas-clean
to clean the Jira database - Run Jira using
atlas-run
You are now ready to run the tests!
npm test
or
npm start
(both commands run the tests)
npm test -- path/to/your/test/file
Add .only()
to your it
or describe
block
Example:
it.only('should do stuff' () => {
...
});
(Do not commit/push tests using .only()
, this will stop all the other tests from running)
To create a report for uploading to Jira/XRay, run
npm run report
To upload the report to XRay, open the test execution issue you want to add the results to. Press the .
button and search for Import execution results
.
This will update the Jira issues of existing tests, and add new issues for new tests
If you want to write new automated system tests, you should read this section!
-
Tests should be in a
describe
block in the formdescribe('TCS: Test <SF NAME>')
, where you replace<SF NAME>
with the name of the system function you are testing. -
Each
describe
should include abefore
method that calls thesetUpJira
function - this is how we can be sure Jira is set up and the ConDec plugin is reset. -
inside the describe block, there should be an
it
block for each test case. Theit
block should be named using should/when syntax describing the rule or exception you are testing. The rule or exception number should be added to the end of the name.Example:
it('should create a new comment for an existing Jira issue when the documentation location "Jira issue text" is selected (R2)'
-
Each test should have a multiline comment preceding it indicating its specification. It should include preconditions, test steps, and postconditions, and should look something like this:
/** * TCS: Test create decision knowledge element should give a new decision the status "decided" (R4) * * System function: Create decision knowledge element * Precondition system: Decision knowledge element with type issue exists * Precondition GUI: WS1.3 (Decision knowledge view) or WS1.4 (Jira issue view) * Test steps: 1. Create a new decision for the issue * Expected result on GUI: The decision is visible on the knowledge graph. A success message is shown. * Expected exception: None * Postcondition system: The new decision has the status 'decided' */
- Mocha - test runner
- chai - assertion library, provides assertion chaining and test fixtures
- we also use the chai plugins chai-like and chai-things, to allow easy assertions for elements of an array and subsets of an object
- axios - HTTP request module
- node-jira-client API reference
- The Node Jira client provides an easy way to access a lot of Jira API endpoints without having to send them with axios.
- Official Jira API reference
- Each test should be atomic - it should not depend on data or objects from other test cases
- If you are trying to find the path to a HTML artifact on Jira, or the REST API endpoint that is called when you click a button, it can help to use the web inspector (Ctrl-Shift-C on Firefox) and view the HTTP requests in the console.