Skip to content

Add Testing Expections to CONTRIBUTING.md #43

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.

Sign up for GitHub

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

Merged
drey-bigney merged 3 commits into from
Sep 23, 2021
Merged

Add Testing Expections to CONTRIBUTING.md #43

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f6f668a
Add Testing Expections to CONTRIBUTING.md
JohnKallies Sep 22, 2021
ac5628c
Update CONTRIBUTING.md
JohnKallies Sep 22, 2021
8224a3b
Merge branch 'develop' into feature/express-testing-expectations
drey-bigney Sep 23, 2021
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
11 changes: 11 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,11 +22,22 @@ We use GitHub's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues).
- All execution paths for new code should be covered by unit tests.
- Many IDEs will report on unit test coverage and call out any gaps. That said, reporting of test coverage doesn't mean that the tests are useful or effective. If you find a section of code is difficult to unit test, this may indicate the need for some refactoring. Non-trivial refactors should also be coordinated with project maintainers.

#### Testing expectations
- The OSMT project embraces the [Test Pyramid](https://martinfowler.com/bliki/TestPyramid.html). Boiling this down:
- We want to test all execution paths with unit tests.
- Unit tests do not rely on any external services, network access, databases, or filesystem I/O, but rather use mocks when required. This also informs good object composition and design, facilitating healthy dependency injection/inversion of control.
- Unit test classes will be run by Maven in the "test" phase by the Surefire plugin, and need to end in "Test".
- We use integration tests as needed to stand up subsets of the application. These may require Docker containers or interactions between several components or services.
- Integration test classes will be run by Maven in the "verify" phase by the Failsafe plugin, and need to end in "IT". Failsafe has "pre-integration-test" and "post-integration-test" phases for standing up and tearing down integration test resources. The "post-integration-test" phase is always processed, regardless of test failures. This allows Maven to clean up and destroy integration test resources.
- We want to have as few E2E (end to end) tests as possible.
- Our E2E tests are implemented in Protractor as automated browser tests, and require walking through functionality on an actual OSMT instance. These are the most expensive and time-consuming tests. They are needed to ensure that layers of the application are wired up correctly, but should be used sparingly.

## Release / Branching Strategy
The OSMT project will follow the [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) model, with
* Enhancement and bug fix work done on feature branches (```feature/branch-name```)
* Feature branches merge into ```develop```, as the integration branch
* Releases are cut from ```develop``` (as ```release-branch-name```), and merged back in to both ```master``` and ```develop```
>

### Using git with this project
1. Use the project's [Issue Tracker](https://github.com/wgu-opensource/osmt/issues) to find an issue that you want to address, or a feature that you would like to add.
Expand Down