[TIP] RFF: Article on python test design pattern - DAI

Olemis Lang olemis at gmail.com
Tue Dec 8 08:08:11 PST 2009


On Tue, Dec 8, 2009 at 10:30 AM,  <exarkun at twistedmatrix.com> wrote:
> On 03:13 pm, olemis at gmail.com wrote:
>>
>> On Tue, Dec 8, 2009 at 9:55 AM,  <exarkun at twistedmatrix.com> wrote:
>>>
>>> On 04:07 am, amax at redsymbol.net wrote:
>>>>
>>>> (that's Request For Feedback)
>>>>
>>>> Hi everyone,
>>>>
>>>> Here is a draft article about a useful design pattern for Python code
>>>> tests:
>>>>
>>>> http://redsymbol.net/articles/deep-assertion-injection/
>>>
[...]
>>>
>>> or a stack capturing
>>> helper which allows for easy annotation of later assertions.
>>
>> Little comment :
>>
>> Modules that contain __unittest = True are hidden in failure
>> tracebacks . Is this what you 'r talking about ?
>
> Nope.  Consider this modified version of one of the snippets from the essay:
>
>   def __init__(self, rel_url, urlopen=urlopen):
>       '''rel_url is the HTTP URL of the resource, relative to the server
> urlopen is the function to open the URL'''
>       url = 'http://{}/{}'.format(self.server, rel_url)
>       try:
>           self.resource = urlopen(url)
>       except:
>           # Blah blah blah
>           self.resource = another_opener(url)
>
[...]
>
> With this version of the code, the exception raised by the failing assertion
> goes nowhere, and the test does not fail (or at least does not fail in the
> "right" way).
>

Now I c . It was /me not understanding what you were saying (and u'r right ;o)

My (ideal) approach in this case is (u know me well here go doctests
once again ;o) to use dutest and run (e.g. by cloning the TCs loaded
out of doctests ;o) the same test code with different values (i.e.
either globs or extraglobs ;o) . In that case, since checking is
performed by monitoring test case execution then things are decoupled
in such a way that I can switch values and reuse test code over and
over and it should still work

For example I want to apply this technique to RPC verification .
Suppose you implement an RPC handler . In that case the logic in there
is (should be) independent of the protocol transport. Such an
arrangement would allow me to write a test once (i.e. to chech the
«business» logic behind the handler) and switch RPC clients or use
multiple instances in order to test multiple protocols (e.g. RPC
handler object directly, XMLRPC client aka ServerProxy, JSON RPC
client , ...)

PS: Please CMIIW and tell me if I'm talking about something else thus
becoming OT

osimons added because of the RPC thing ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:



More information about the testing-in-python mailing list