How to stub out a method regardless of which arguments are used?

[Christoph Neuroth]

Hi,

when using when(Class).method(arg1, arg2,...) test cases can get
unneccessarily complex IMHO. Consider a method foo:

def foo(self, foo):
result = ExternalDependency.do_stuff_with_it(self.get_some_thing,
self.get_some_other_thing() * 7 - 3, None)
# ...

Now in the test, I just want to catch the call to
"ExternalDependency.do_stuff_with_it" - as it is called exactly once,
I don't care about the arguments, but I have to construct the same
arguments list in my test case, which is time-consuming, error-prone
and just plain boring ;) I would prefer to write something like this
in my test:


when(ExternalDependency).do_stuff_with_it(mockito.any_arguments).thenReturn(....)

cheers, Chris

[Serhiy Oplakanets]

I see your point. There is no way so far to say smth like
"any_arguments()", but you can use "any()" matcher to have your
stubbing and/or verification bit shorter. In your example it will look
like:

>>> from mockito.matchers import any
>>> when(ExternalDependency).do_stuff_with_it(any(), any(), any()).thenReturn(....)

But I like your idea with "any_arguments()" matcher. Please request a
feature at http://code.google.com/p/mockito-python/issues/list if you
don't mind.

-- Serhiy


On Aug 3, 11:51 am, Christoph Neuroth

[szczepiq]

Cool idea. You may consider making it even shorter: 'any_args()'

cheers,
Szczepan

--
You received this message because you are subscribed to the Google Groups "mockito-python" group.
To post to this group, send email to mockito...@googlegroups.com.
To unsubscribe from this group, send email to mockito-pytho...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/mockito-python?hl=en.

[Christoph Neuroth]

On Aug 3, 11:28 am, Serhiy Oplakanets <ser...@oplakanets.com> wrote:
> I see your point. There is no way so far to say smth like
> "any_arguments()", but you can use "any()" matcher to have your
> stubbing and/or verification bit shorter. In your example it will look
> like:
>
> >>> from mockito.matchers import any
> >>> when(ExternalDependency).do_stuff_with_it(any(), any(), any()).thenReturn(....)

Aaaah yes thank you, that is what I'm looking for :)

> But I like your idea with "any_arguments()" matcher. Please request a
> feature athttp://code.google.com/p/mockito-python/issues/listif you
> don't mind.

Do you prefer using googles tracker or the one at bitbucket? This is
also a bit misleading on the project page, because it contains links
to both...

Chris

[Serhiy Oplakanets]

True. We are in process of moving to Google Code.
I prefer using both, but tat is indeed a bit confusing. Please use
Google's Tracker.

[Christoph Neuroth]

On Aug 3, 2:31 pm, Serhiy Oplakanets <ser...@oplakanets.com> wrote:
> True. We are in process of moving to Google Code.
> I prefer using both, but tat is indeed a bit confusing. Please use
> Google's Tracker.

Okay, I reported it. There was no way to select "enhancement" or
anything though, so its listed as defect now. Also reported two bugs
on bitbucket earlier :) Generelly, I prefer the bitbucket interface to
google code, which is just messy...

Chris

[Serhiy Oplakanets]

Great, Thanks!
I generally like bitbucket, but wiki is terrible there. No way to make
proper structured documentation.
I also like github, probably the most. But since python community
don't really like github I decided not to use it :)

[Christoph Neuroth]

Hehe yes github... Never got used to it either. For structured
documentation (if you can live without the wiki), IMHO nothing gets
even close to sphinx :)

[szczepiq]

>I generally like bitbucket, but wiki is terrible there.

Really? :) I always thought that bb wiki is better than googlecode but maybe I didn't exploit it too much. Anyways, I don't mind either.

@Serhiy do you think it makes sense to kill bb repo in favor of googlecode?

Cheers,
Szczepan

--

[Bartosz Bańkowski]

I remember we wrote first version of mockito-python using googlecode and then moved to bitbucket. History comes full circle... :)

Best regards,
Bartosz

[Serhiy Oplakanets]

Maybe... I don't know. I like both, but as said it's terrible for users.

I want to also try sphinx and then make my mind. My first evaluation of Sphinx wasn't that successful. Comparing to Javadoc it looked like black magic to me :)

What do you vote for?

-- Serhiy

[szczepiq]

Up to you Serhiy :), we moved from gc to bb because we wanted to use mercurial. Now days gc supports mercurial so we're good.

Cheers,
Szczepan

[Christoph Neuroth]

On Aug 3, 10:44 pm, Serhiy Oplakanets <ser...@oplakanets.com> wrote:
> I want to also try sphinx and then make my mind. My first evaluation of Sphinx wasn't that successful. Comparing to Javadoc it looked like black magic to me :)

Thats apples and oranges ;) Sphinx is about writing documentation with
a bit of embedded code documentation from python docstrings. So you
can write about when() and have a nice link to the documentation (and
source code) of the when function. Javadoc just creates API docs from
the docstrings (or whatever they're called in Java world). The
equivalent to Javadoc would be ePydoc, Sphinx is a bigger thing... For
Java itself, there is the API docs, but theres also other things as
the Java Tutorials site at Oracle because Javadoc just isn't the right
tool to generate user-friendly documentation. And thats fine. A
detailed tutorial of a complex system doesn't belong in a docstring.

Also its not that important where the project is hosted. Just make
sure it is easy for users to identify the official, "master" home
page. No one (okay, no developer which is your target audience ;))
cares if thats a nice homepage (like lettuce ;)), a google code or
bitbucket page. Just make sure it is the first hit on google and it
provides links to the official bug tracker and the most recent code.
This is a problem with many projects since DCVS gained so much
popularity (which is a good thing): Users don't know where to get the
latest code and don't know where to drop comments, feature requests
and report bugs - and that hurts the project.

Chris

[Serhiy Oplakanets]

Regarding apples and oranges: I meant that if I find Sphinx suitable I
can make tutorial with it and the upload to packages.python.org.
And regarding Javadoc, I meant that such a simple library if it has
well documented api with examples in it probably doesn't need former
tutorial. As in older mockito.

Anyways, I'll find some time this weekend and will try to finally
choose one place for mockito home. Thanks for constructive critics,
Chris.

-- Serhiy

On Aug 4, 9:57 am, Christoph Neuroth