[TIP] Mocking the .decode(...) method on a string
ned at nedbatchelder.com
Wed Aug 29 08:02:19 PDT 2012
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python