Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain project conventions #17

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions end2end/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,30 @@ npx playwright install
- GitHub Actions workflow? **N**
- Install browsers? **Y**

## Developing New Tests

Before developing new tests, please familiarize yourself with the following requirements.

### Synchronize your database

Before starting development, you must run the API tester ([How do I do this?](../README.md#running-tests)). This helps ensure that tests run consistently across all developer workstations.

### File Organization

Individual tests that can run in parallel must organized into files by their functional location. The functional location refers to the page in which the function occurs. For example, the Form Editor exists in the Admin Panel. Therefore the file would be named `adminPanelFormEditor` + file extension. Most tests should fall into this category.

Inter-dependent tests that exercise a series of features must be prefixed with `lifecycle`, and briefly describe its function. For example, `lifecycleSimpleTravel` implements a simple travel workflow, creates a record, applies approval actions, and builds a report.

Files must use camelCase. No spaces are permitted in filenames. Underscores should be used in lieu of spaces if needed.

### Naming Tests (Titles)

Test Titles must briefly and plainly explain the component or feature it exercises. For example, if we're creating a test on the homepage to check the search box's ability to find a specific record in a certain way, the title can be `search [specific record] using [method]`. It's not necessary to explain that the test is for the homepage, because this is implicit in the filename. Titles must be formatted in plain language, no naming conventions such as CamelCase should be used for the whole title.

### Screenshots

Including screenshots within tests is highly recommended, but not currently required. Screenshots provide value when reviewing tests, as it can be immediately apparent in a screenshot if a test is functioning correctly.


## Useful commands

Expand Down
Loading