[TIP] Mocking the .decode(...) method on a string

[Ned Batchelder]

Ah, I see.  But then the successful tests are also relying on the 
getpreferredlocale() value, or you are specifying explicit encodings in 
the tests? I would still avoid mocking here.

--Ned.

On 8/29/2012 10:31 AM, Alexander O'Donovan-Jones wrote:
>
> Twofold: first is to get an understanding of mocking complex things 
> such as __builtin__ methods/classes/objects.
>
> Secondly, the example I gave is contrived. The actual use of this code 
> relies upon a return from locale.getpreferredlocale() to determine the 
> desired encoding to use. If I specify 'cp1252' on computer A, with a 
> Russian installation of Windows and it throws the UnicodeDecodeError 
> then the test passes. However if I run it on computer B, with a 
> different character set as default and the UnicodeDecodeError isn't 
> thrown, then my test fails, due to differences in the operating 
> system, outside of my control.
>
> I want to control the execution of the function to ensure that the 
> return after encountering the exception is correct and not leave it to 
> a variable in the operating system to arbitrarily decide whether or 
> not the test should pass.
>
> *From:*Ned Batchelder [mailto:ned at nedbatchelder.com]
> *Sent:* Wednesday, 29 August, 2012 2:14 PM
> *To:* Alexander O'Donovan-Jones
> *Cc:* testing-in-python at lists.idyll.org
> *Subject:* Re: [TIP] Mocking the .decode(...) method on a string
>
> On 8/29/2012 10:02 AM, Alexander O'Donovan-Jones wrote:
>
>     Creating a mock object that raises the exceptions required is
>     exactly the route I'm taking now.
>
> Yes, I can see that, but it's causing you trouble, and you can instead 
> simply use two arguments to the function that will raise the 
> exception, no?  I'm not sure why mocking is the better approach here.
>
> --Ned.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20120829/b76594c0/attachment-0001.htm>