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

Refactor into Reporter Interface #113

Merged
merged 3 commits into from
Aug 9, 2017
Merged

Refactor into Reporter Interface #113

merged 3 commits into from
Aug 9, 2017

Conversation

bradleyfalzon
Copy link
Owner

Previously the GitHub handler was solely responsible for reporting issues, but in the near future, the Analyser package will begin to be responsible for it.

To do this, we'll create an analyser.Reporter interface with a single method Report(context.Context, []db.Issue) error. GitHub handler is then responsible for determining which reporters it requires and then executing those reporters.

GitHub handler will still be responsible for calling the Report methods, but this will eventually change, and instead, GitHub handler will just be responsible for instantiating the types and passing them to Analyser.

This change is mostly moving the two reporters (Pull Request Comments and Status API) to their own types that implement the analyser.Reporter interface.

Additional reporters will be available in #75 (commit comments) and #112 (pull request reviews).

Included: Integration tests to test for states being set in order

Previously the github.Analyse test was responsible for testing that
the Status API states were being set in the correct order. This
complicated the testing and we'll shortly be duplicating some of that
functionality and tests into its own type.

In moving to its own type, we won't be able to track the order of
statuses, we want to see Pending be set first, followed by Success. The
unit tests will test to make sure the status API can set the status
correctly, but won't have visibility in the order they occur.

Instead, the integration tests, which are already checking the status
API statuses will be responsible to ensure the state transitions from
Pending to Success/Failure or Error.

Previously the github.Analyse test was responsible for testing that
the Status API states were being set in the correct order. This
complicated the testing and we'll shortly be duplicating some of that
functionality and tests into its own type.

In moving to its own type, we won't be able to track the order of
statuses, we want to see Pending be set first, followed by Success. The
unit tests will test to make sure the status API can set the status
correctly, but won't have visibility in the order they occur.

Instead, the integration tests, which are already checking the status
API statuses will be responsible to ensure the state transitions from
Pending to Success/Failure or Error.
type StatusState string

const (
StatusStatePending StatusState = "pending"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golint: exported const StatusStatePending should have comment (or a comment on this block) or be unexported

StatusStateFailure StatusState = "failure"
)

type StatusAPIReporter struct {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golint: exported type StatusAPIReporter should have comment or be unexported


var _ analyser.Reporter = &StatusAPIReporter{}

func NewStatusAPIReporter(client *github.Client, statusURL, context, targetURL string) *StatusAPIReporter {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golint: exported function NewStatusAPIReporter should have comment or be unexported

}
}

func PRCommentReporter_report(t *testing.T) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golint: don't use underscores in Go names; func PRCommentReporter_report should be PRCommentReporterReport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant