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.

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

Test Driven Development #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Test Driven Development #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
22 changes: 20 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,9 @@
* [General Principles](#general-principles)
* [Ticket Tracking Workflow](#ticket-tracking-workflow)
* [GitHub Workflow](#github-workflow)
* [PR etiquette](#pr-etiquette)
* [Development](#development)
* [XTDD](#xtdd)
* [PR Etiquette](#pr-etiquette)
* [Contributors](#contributors)
* [Reviewers](#reviewers)
* [Performance](#performance)
Expand Down Expand Up @@ -55,7 +57,23 @@
* If you assign someone to your PR you will also have moved the JIRA ticket to IN REVIEW. _You may remain the assignee on the JIRA ticket_. We don't want to inundate assigned reviewers with notifications and constantly update assignments across multiple systems as PRs go through a review process. But **if a blocking review is taking more than 48 hours** to complete, assigning the PR reviewer in JIRA in addition to GitHub is a polite and appropriate way to spur them on and to indicate who is responsible for moving the ticket forward.
* DONE tickets are much more valuable than IN PROGRESS tickets. Unless context switching will cause inefficiency, you should prioritize working on tickets that need minor revisions or refactoring after a review rather than beginning or continuing work on a more recent ticket.

## PR etiquette
## Development

### XTDD

Test Driven Development is a frequently mis-used catchall term for development
practices that incorporate the writing of tests before or during a feature
implementation workflow. Like many teams we've determined that strict, dogmatic
TDD is not particularly helpful or productive. That said, **we do use tests
to drive our development and ensure against regressions**. This section is
intended to describe our testing philosophy, which can loosely be described as
a combination of TDD, Acceptance Test Driven Development and Behavior Driven
Development. Given the broad understanding of these terms we find it is somewhat
unhelpful to adhere rigorously to one or the other; instead we encourage good
judgement and a familiarity with the underlying motivations of these different
but similar test-driven workflows.

## PR Etiquette

### Contributors

Expand Down