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

tests in groovy #32

Open
przemekgalazka opened this issue Sep 4, 2013 · 17 comments
Open

tests in groovy #32

przemekgalazka opened this issue Sep 4, 2013 · 17 comments

Comments

@przemekgalazka
Copy link
Member

Hi :)
lately I was doing some groovy tests and I think that using Jukito in groovy test would be very cool.

What do you think?

DI with Guice in Groovy described here
http://blog.stannard.net.au/2010/05/18/dependency-injection-with-groovy-and-google-guice/

@christiangoudreau
Copy link
Member

Would be very cool! What is the adoption of Guice in Groovy like?

@przemekgalazka
Copy link
Member Author

the adoptions is ok, and just work according to info in this post http://blog.stannard.net.au/2010/05/18/dependency-injection-with-groovy-and-google-guice/

I just wonder about our custom JunitRunner

@olafleur
Copy link
Member

@przemekgalazka Is that a feature request? Do you want to do it?

@przemekgalazka
Copy link
Member Author

hmmm. Right now I am quite sure that jukito could be used with junit tests
written in groovy right away.

However, a spock extension should be a good idea.

@christiangoudreau
Copy link
Member

Did you got a chance to investigate this? We're not using groovy at all (yet), so we're kinda short on testing resources for that.

@przemekgalazka
Copy link
Member Author

Lately I was doing a lot Spock tests (pure groovy). I must say that mocking in Spock is strange and Jukito features like automocking with mockito would be very cool. So to sum up, Jukito should be good to go with pure junit tests in groovy. Spock extension supporting guice could be armed with automocking too. Btw, I liked Jukito idea so much that I did similar solution for Spring https://github.com/przemekgalazka/irmina

@christiangoudreau
Copy link
Member

Seems like a good idea! The problem is that we don't have anyone in the
team that worked a lot with Groovy.

As for spring, it would be great to support some of this natively. We're
also using extensively spring in a lot of projects. Since we're using Javax
annotations and ctor injection, we never really had to botter about spring
annotations. Any use case besides using Config class from spring instead of
Guice modules?

Cheers,

Christian Goudreau | CEO - Président
M: 1.877.635.1585
ArcBees http://www.arcbees.com/ | Blog http://blog.arcbees.com/ |
Facebook https://www.facebook.com/arcbees | LinkedIn
http://www.linkedin.com/company/arcbees

On Sun, Feb 15, 2015 at 10:27 AM, Przemek Galazka [email protected]
wrote:

Lately I was doing a lot Spock tests (pure groovy). I must say that
mocking in Spock is strange and Jukito features like automocking with
mockito would be very cool. So to sum up, Jukito should be good to go with
pure junit tests in groovy. Spock extension supporting guice could be armed
with automocking too. Btw, I liked Jukito idea so much that I did similar
solution for Spring https://github.com/przemekgalazka/irmina


Reply to this email directly or view it on GitHub
#32 (comment).

@przemekgalazka
Copy link
Member Author

Try groovy just for fun. It's easy to use - 3 days and you are a master :)
I did not get you question. What do you mean?

@christiangoudreau
Copy link
Member

Well, we're heavily using Spring and Jukito without modifications to Jukito, I guess my question is: What are your use case that needs spring specific usage?

@przemekgalazka
Copy link
Member Author

how can you do that? Could you give me some examples (jukito + spring) ?
My use case is typical. Every spring tests that needs a few spring beans
and mocks.

Pozdrawiam
Przemek Gałązka

On Fri, Feb 20, 2015 at 5:06 PM, christiangoudreau <[email protected]

wrote:

Well, we're heavily using Spring and Jukito without modifications to
Jukito, I guess my question is: What are your use case that needs spring
specific usage?


Reply to this email directly or view it on GitHub
#32 (comment).

@christiangoudreau
Copy link
Member

We simply use Javax annotations and use CTOR injection :D There's no "magic", but we can't use Spring config file doing that.

@przemekgalazka
Copy link
Member Author

so with Irmina now you can :)

On Mon, Mar 2, 2015 at 2:29 PM, christiangoudreau [email protected]
wrote:

We simply use Javax annotations and use CTOR injection :D There's no
"magic", but we can't use Spring config file doing that.


Reply to this email directly or view it on GitHub
#32 (comment).

@christiangoudreau
Copy link
Member

We had a discussion with the team yesterday about that and it ended up into our nice to have feature list. I'm wondering it there would be more non intrusive way of doing it while using the JukitoRunner.

What do you think?

@przemekgalazka
Copy link
Member Author

At first I was thinking about adding this feature to Jukito. But it's
appeared that it is not about runner but spring custom ContextLoader.
It is dooable but is it worth to complicate jukito so much?

On Tue, Mar 10, 2015 at 6:58 PM, christiangoudreau <[email protected]

wrote:

We had a discussion with the team yesterday about that and it ended up
into our nice to have feature list. I'm wondering it there would be more
non intrusive way of doing it while using the JukitoRunner.

What do you think?


Reply to this email directly or view it on GitHub
#32 (comment).

@christiangoudreau
Copy link
Member

I'm really not sure, but that would go along the road of using other DI configuration files. I don't really want to use Spring context loader, but read a config file and do the appropriate mapping as if I would use "install".

But I may be overthinking it and it may be not useful at all. The other DI framework that I would like to support would be Dagger.

@przemekgalazka
Copy link
Member Author

hmm, only common thing here is mocks register so this could be overthinking
:)

On Wed, Mar 11, 2015 at 1:37 PM, christiangoudreau <[email protected]

wrote:

I'm really not sure, but that would go along the road of using other DI
configuration files. I don't really want to use Spring context loader, but
read a config file and do the appropriate mapping as if I would use
"install".

But I may be overthinking it and it may be not useful at all. The other DI
framework that I would like to support would be Dagger.


Reply to this email directly or view it on GitHub
#32 (comment).

@RaviH
Copy link

RaviH commented May 18, 2015

+1 for Jukito port to Spock with Guice injections!

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

No branches or pull requests

4 participants