See the Root repository for full project information and an overview of how services fit together.
SIA is built using:
SIA is configured for Wepback's hot module reloading, so changes should automatically appear in your browser.
- Node.js (latest LTS is preferred)
You will need to add const files in config for each environment you want to use; these are not tracked in git. See cfg/constExample.js for more details. Const files follow the naming convention $env.const.js (localhost.const.js is the const file loaded by localhost.js, for example).
Use these steps to launch if you're hosting your Gateway API locally.
- Navigate to the SIA-EventUI source directory root
- Ensure your local copy of the gateway API is running on http://localhost:50000 (or the base URL you configured)
- Enter these commands to launch the Event UI:
npm install npm start - Navigate to http://localhost:3000
Use these steps if you're working on the Event UI and do not need to run a local copy of the gateway.
- Create a localhost.const.js file inside the cfg folder. Use the
cfg/constExample.jsfile as a template. - Navigate to the SIA-EventUI source directory root
- Enter these commands to launch the Event UI:
npm install npm run serve - Navigate to http://localhost:3000
- Enter this command:
npm test
For bugfixes, write a failing test before you change the code.
For feature work we expect code to be reasonably well tested, which means:
- A happy path through the feature should be illustrated.
- Any exception or error handling should be tested.
- failbacks for sad paths can be tested as well, though it is not required.
- Features which handle user input should have validation tests describing when the input is valid or invalid.
BDD style is being adopted in the codebase, but it was introduced in stages, so many tests aren't using this approach. Familiarize yourself with the Chai.js BDD documentation.
- test messages should be human-readable and accurately describe the test.
- Use
describeandcontextblocks to establish the context of the method under test, anditblocks to describe expectations.describeshould be used to name the object under testcontextshould be used to enumerate the conditions in the test, and begin with 'when'.itblocks should begin with 'should' and list the expectation.- See the first three sections of betterspecs.org for more details.
- Avoid writing more than one
expectperitblock. - When submitting a pull request, try to include a user story illustrating the happy path of your feature.
- Any changes to the UI should include before and after screenshots. Or gifs!!
- In code review, avoid approving if you are not confident in your understanding of the code. Approve after you've pulled the change into your local environment and manually validate.
How should we approach UI testing versus business logic?
- UI components can be treated as purely functional, and can be tested easily, but these tests are usually not high-value.
mapStateToPropsand other non-render functions should be tested separately.- we need to test all user interactions like onClick, or onSubmit, or onHover… anything which is configured to dispatch an action should be tested.
- All paths through the function must be tested
- When state is not changed use strict equality
.equal(check). - When state is changed… use
.deep.equalto compare it to the expected.
- An action which returns a static object may safely be untested.
- When an action conditionally returns differing values, tests should be written to cover at least the happy path.
- Thunks (actions which take dispatch as an argument and dispatch multiple actions) should use a mock dispatch to ensure that the correct actions are dispatched in the correct order
webpack --env=dist
A partial list of run scripts and what they do
| Script | What it does |
|---|---|
| start | Launch the server and point at a gateway hosted on localhost (use localhost.const.js) |
| serve | Launch the server and point at a gateway hosted in the dev environment (use dev.const.js) |