I don't feel competent to contribute to the kind of test framework you're
proposing, because I wouldn't be using it myself. I think that the right
progression should be something like this:
1. You discover that you have a similar need in several tests and write
some support code.
2. You refactor
Am 22.07.2014 23:13, schrieb Guido van Rossum:
I don't feel competent to contribute to the kind of test framework
you're proposing, because I wouldn't be using it myself. I think that
the right progression should be something like this:
1. You discover that you have a similar need in several tes
On Tue, Jul 22, 2014 at 6:00 PM, Tobias Oberstein <
tobias.oberst...@gmail.com> wrote:
> So I guess what I am after is "six for asyncio/Twisted" ;)
Isn't "six for asyncio/Twisted" covered by the fact that you can implement
one event loop in terms of another? Idiomatic asyncio code and idiomatic
So I guess what I am after is "six for asyncio/Twisted" ;)
Isn't "six for asyncio/Twisted" covered by the fact that you can
implement one event loop in terms of another? Idiomatic asyncio code
Yep, wrapping a network library for some protocol written for network
framework X for users to r
On July 22, 2014 at 7:54:17 AM, Tobias Oberstein (tobias.oberst...@gmail.com)
wrote:
Hi,
I am maintaining AutobahnPython, a library that supports Twisted and
asyncio/Trollius in one codebase.
Now, ideally, I'd like to write unit tests that work across all variants
- while avoiding code d
In Twisted, there is Trial, which provides an extended version of
unittest.TestCase with this feature:
"""
The main unique feature of this testing class is the ability to return a
Deferred from a test-case method. A test method which returns a
snip
I strongly recommend you reconsider doing t
On July 25, 2014 at 9:08:46 AM, Tobias Oberstein (tobias.oberst...@gmail.com)
wrote:
>> In Twisted, there is Trial, which provides an extended version of
>> unittest.TestCase with this feature:
>>
>> """
>> The main unique feature of this testing class is the ability to return a
>> Deferre
And: I'm sure Twisted developer's will have reasons for frowning upon
tests returning deferreds, but could you recap shortly why?
It has the classic problem with bad tests: reliance on global state
which is not controlled by the test. Unit tests should be isolated, they
should not affect or rel
>
>
> I strongly recommend you reconsider doing this.
>
> The Twisted core developers have, for several years now, mostly eschewed
> the usage of returning Deferreds from test cases. Instead, tests are
> written by explicitly controlling all events explicitly, with careful use
> of test doubles to
On Jul 25, 2014, at 7:46 AM, Tobias Oberstein
wrote:
> E.g., for integration tests, we (Autobahn|Python) have Autobahn|Testsuite,
> which actually tests interaction of components over the network.
>
> For low-level (per function) testing, we have (synchronous) unit tests.
>
> But there is a
There's another thing. If you accidentally put a yield in a test_*()
method, and you are using the default test runner, it will silently succeed
without doing anything (since calling it just creates the generator object
without starting the code). That's annoying. I personally think that this
shoul
11 matches
Mail list logo
