Dear Eric & Carl<br><br>Thanks to both of you. Yes. Eric, your solution calls the mock version (I modified the assert a bit because, I think the the expected output is `args=['123']` rather than `args='123`).<br>
<br>The snippet of the old mock and new mock is found here: <a href="http://dpaste.org/vPswS/">http://dpaste.org/vPswS/</a><br><br>Observations:<br>1. test cases return `codebundle.tests`<br>2. inside render_reverse, it returns `codebundles.lib` (guess this means it is returning the local binding of `reverse`)<br>
<br>Yes. I am aware of the nice feature in 1.4, but I have to first verify them in my old Django (I am running 1.2.1.... omg)<br><br><br>> The assertion of the result might be pointless, but it feels like it
confirms what the code under test should produce. <br>> Also, I realize I
dropped the "dummy_views" from the argument simply b/c it seems
superfluous in my example. <br>> Obviously, if it necessary, then it is
necessary and should be in the test… right?<br><br>Not at all. Like Carl said, it was pointless and bad to supply mock objects to the arguments in many cases. In this particular case, they are just `string type`. A dummy `foo` string will do it. I think these two assertions are good (although many people follow the one assertion per test rule). So if you want to assert that it did call with the args we passed in, for the sake of "getting the right info of what goes wrong", we can write a test for each assertion. Actually, I am new to this mailing list so I created a duplicate. Carl explains this really well in his first reply: <a href="http://lists.idyll.org/pipermail/testing-in-python/2012-April/004913.html">http://lists.idyll.org/pipermail/testing-in-python/2012-April/004913.html</a><br>
<br><br>--<br>John<br><br>
<div class="gmail_quote">On Thu, Apr 12, 2012 at 3:46 PM, Eric Larson <span dir="ltr"><<a href="mailto:eric@ionrock.org">eric@ionrock.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thursday, April 12, 2012 at 2:18 PM, John Wong wrote:<br>
> First, I hope I am not making duplicate (my first time using this kind of mailing list...)<br>
><br>
> > The first thing is to be clear in your mind which code you are intending<br>
> > to test. In this case, it sounds like you want to test your<br>
> > "render_reverse" function, but without exercising Django's "reverse"<br>
> > (which makes it a unit test). Mocking "reverse" is a reasonable way to<br>
> > go about this.<br>
><br>
><br>
> Yes. Exactly. I want to perform a unittest on this function, which calls django's reverse (for whatever reason why I am doing this...)<br>
><br>
> Here is the actual function from lib.py (there is no class involved, all functions in lib.py)<br>
><br>
> from django.core.urlresolvers import reverse<br>
> def render_reverse(f, kwargs):<br>
> """<br>
> kwargs is a dictionary, usually of the form {'args': [cbid]}<br>
> """<br>
> return reverse(f, **kwargs)<br>
><br>
> Because the name lookup is `reverse`, so I should patch `myproject.myapps.mylibrary.reverse` as opposed to `django.core.urlresolvers.reverse`<br>
><br>
> I did the first method. I want to assert that `render_reverse` generates whatever `reverse` generates (by calling `reverse` directly). That's the goal. So I have the following test code:<br>
><br>
> from lib import render_reverse, print_ls<br>
><br>
> class LibTest(unittest.TestCase):<br>
><br>
> def test_render_reverse_is_correct(self):<br>
> with patch('myproject.myapps.mylibrary.reverse') as mock_reverse:<br>
> from lib import render_reverse<br>
> mock_f = MagicMock(name='f', return_value='dummy_views')<br>
> mock_kwargs = MagicMock(name='kwargs',return_value={'args':['123']})<br>
> mock_reverse.return_value = '/natrium/cb/details/123'<br>
> response = render_reverse(mock_f(), mock_kwargs())<br>
> print mock_reverse.mock_calls # prints []<br>
> print mock_reverse.mock_calls # prints []<br>
> self.assertTrue('/natrium/cb/details/' in response)<br>
><br>
<br>
</div></div>I might consider rewriting the test like this:<br>
<br>
import lib<br>
import mock<br>
<br>
@mock.patch.object(lib, 'reverse')<br>
def test_render_reverse(mock_reverse):<br>
result = lib.render_reverse('foo', {'args': ['123']})<br>
mock_reverse.assert_called_with('foo', args='123')<br>
assert result == mock_reverse('foo', args='123')<br>
<br>
The assertion of the result might be pointless, but it feels like it confirms what the code under test should produce. Also, I realize I dropped the "dummy_views" from the argument simply b/c it seems superfluous in my example. Obviously, if it necessary, then it is necessary and should be in the test… right?<br>
<br>
If others have comments on my refactoring please let me know. I'm new to the mock library and have been in the process of updating a rather old and unorganized test suite, so tips, tricks and best practices are all appreciated.<br>
<br>
Thanks!<br>
<br>
Eric<br>
<div class="im">><br>
> Observations:<br>
> 1. mock_reverse was never because `mock_calls` returns []. I've asserted with `called` method, and it returns False.<br>
> 2. using render_reverse like this, the name `dummy_views` must exists - it must be a view function that actually exists in my Django project. Otherwise, it will return an error.<br>
> 3. using render_reverse like this, the speed takes 0.2 - 0.3 seconds, as opposed to 0.06 s when I used `mock_reverse`.<br>
><br>
> Is there anything wrong the code? I understand that `mock_f` and `mock_kwargs` should be just simple input, rather than mock objects.<br>
><br>
> Thanks, Carl.<br>
</div>> _______________________________________________<br>
> testing-in-python mailing list<br>
> <a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a> (mailto:<a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a>)<br>
> <a href="http://lists.idyll.org/listinfo/testing-in-python" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
<br>
<br>
<br>
</blockquote></div><br>