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

Abstract Connection to an interface #33

Closed
JELGT2011 opened this issue May 2, 2017 · 2 comments
Closed

Abstract Connection to an interface #33

JELGT2011 opened this issue May 2, 2017 · 2 comments

Comments

@JELGT2011
Copy link
Contributor

Apologies if this has already been suggested or if this is not the proper channel for suggesting feature requests. Also, I'm totally willing to make this PR myself, I just want to see how the authors feel about it before actually going about making the code changes.

Abstract stompngo.Connection to an interface to allow mock generators to mock the connection and allow for easier testing. Use a different name to not break backwards compatibility. So something like:

type STOMPConnection interface {
	Send(stompngo.Headers, string) error
	Connected() bool
	Disconnect(headers stompngo.Headers) error
	Subscribe(headers stompngo.Headers) (<-chan stompngo.MessageData, error)
	Unsubscribe(headers stompngo.Headers) error
	Ack(headers stompngo.Headers) error
	Nack(headers stompngo.Headers) error
}
@JELGT2011 JELGT2011 changed the title Abstract stompngo.Connection to an interface Abstract Connection to an interface May 2, 2017
@gmallard
Copy link
Owner

gmallard commented May 3, 2017

There are no objections to this , at least in concept.

Please pursue this yourself, and submit a PR when complete.

Please add:

    Begin(...) ....
    Commit(...)...
    Abort(...)...

to the interface.

This package currently does not mock anything in tests. It depends on the availability of a running message broker.

Therefore, some actual mock tests would also be required in the PR.

Given the general theme of go interfaces I was thinking STOMPConnector for the interface name. But I can go either way on that.

Rule One: no external dependencies other than stdlib in the main package. Adding external dependencies to tests would be accepted assuming those dependencies appear to be stable and well supported.

Rule Two: try to use idiomatic variable names. Keep them short.

I can be flexible about rule two. Rule one, not so much.

Ask other questions at any time.

@gmallard
Copy link
Owner

See: 5d91fde

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

No branches or pull requests

2 participants