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

Already on GitHub? Sign in to your account

Support a standalone proxy mode #89

Closed
robfletcher opened this Issue Jul 31, 2013 · 11 comments

Comments

Projects
None yet
4 participants
Collaborator

robfletcher commented Jul 31, 2013

Currently Betamax is very closely coupled to the JUnit @rule mechanism. This is fine for JUnit & Spock users but not for TestNG, ScalaTest, etc. Although it's possible to start up the proxy programmatically it's not very convenient. It's also a bit of a code smell that the Recorder class is at once the central entry point for the Betamax API and the JUnit rule implementation. It would make sense to separate the two concepts.

rslifka commented Aug 1, 2013

Hi Rob,

I'm wondering if it's easier to have a separate repo that has some Scala helpers that glue the two together? We'll publish something in the next 24-48 hours here:

https://github.com/sharethrough/scala_betamax

Rob

Collaborator

robfletcher commented Aug 1, 2013

Sounds like a great idea although I'm sure there are still things about the
API that could make such helpers easier to implement.

I've just started working on some big updates (#66 & #85) & there's a lot I
want to tidy up as I go.

rslifka commented Aug 1, 2013

Sure thing Rob, mentioning @mrpotes as he crushed it here - http://www.scottlogic.com/blog/2013/07/18/betamax-in-scala.html.

mrpotes commented Aug 1, 2013

There were a couple of private methods that it would be useful to have access to IIRC. I'll try and remember what they were.

Some extra scala support would be good, but I wonder if it might actually be better off in the core betamax rather than split off elsewhere? The only problem then is compiling for multiple scala versions - maybe you'd want to rebundle just for scala so that other jvm languages aren't exposed to that pain?

Collaborator

robfletcher commented Aug 1, 2013

One of the things I'm doing is splitting the library up into a multi-module
build. The idea is you'll still just include a single dependency –
betamax-proxy or betamax-httpclient at this stage – and they will
transitive lay pull in betamax-core, etc. a Scala adapter could fit well
into that model.

I also want to decouple the Betamax runtime from the JUnit rule
implementation so you can use the former without the latter.

rslifka commented Aug 1, 2013

Funny enough, @rweald and I are having this conversation now at Sharethrough :) How about the pattern of creating a separate betamax-X repo per JVM variant bridge? That way the Betamax core (or whatever modules it's broken into) are clean with respect to core Java and that simplicity in maintenance and usage stays. Any concerns with respect to variant-specific helpers are isolated into those separate repos.

I would want Rob to have the freedom to evolve Betamax without a ton of concern to every variant that might wish to idiomatically provide access to its preferred testing frameworks. Granted, some of the changes we'll discuss (re: private methods which @mrpotes, I also was hoping weren't private :) will help all variants incl. Java.

(basically, what @robfletcher just said ;)

mrpotes commented Aug 1, 2013

Sounds good. Once you've done your restructuring @rslifka and I can fork and provide a scala module if you like?

rslifka commented Aug 1, 2013

+1

We'll hold off on sharethrough/scala_betamax for the time being since it would be preferable to have this part of the official core set of modules. @mrpotes, I like your approach of providing wrappers and options per testing framework. Looking forward to it!

Collaborator

robfletcher commented Aug 1, 2013

That's pretty much exactly what I have in mind. I want to break the
dependency on Groovy (simply to make the dependency graph smaller). Groovy
itself wouldn't need any kind of language bridge but that option should be
there for languages that can benefit. Probably not something I'm likely to
work on myself but I'll be happy to discuss API changes that can help such
things.

On Thursday, August 1, 2013, Rob Slifka wrote:

We has basically the conversation we're having in this issue at
Sharethrough :) How about the pattern of creating a separate betamax-X repo
per JVM variant bridge? That way the Betamax core (or whatever modules it's
broken into) are clean with respect to core Java and that simplicity in
maintenance and usage stays. Any concerns with respect to variant-specific
helpers are isolated into those separate repos.


Reply to this email directly or view it on GitHubhttps://github.com/robfletcher/betamax/issues/89#issuecomment-21963867
.

mrpotes commented Aug 8, 2013

@robfletcher @rslifka I've started creating scala support modules at mrpotes/betamax - let me know what you think.

Collaborator

cowboygneox commented Jan 1, 2017

Moving to Trello: https://trello.com/c/MEwtr6m2

@cowboygneox cowboygneox closed this Jan 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment