| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
In bridgedb.Bridges.FilteredBridgeSplitter.prepopulateRings(), we return
False if we were unable to prepopulate bridges into the sub hashring for
whatever reason. In case some calling function wants to use the boolean
return value as a check, we should mirror this logic and return True if
prepopulation was successful.
|
| | |
| |
| |
| |
| |
| | |
* CHANGE bridgedb.Bridges.parseStatusFile() to only log networkstatus
descriptor fields if the parsers were actually able to parse
them. Otherwise we waste a lot of log lines with blank values.
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
[ci skip]
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It was still failing.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The random IP address generation in these old unittests would mean that
some tests would unreproducibly fail due to their fakeBridge()s using
invalid IP addresses.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This was causing problems for the parsers, some of which expect an IPv6
address without brackets, and others with brackets. It's easier if we're
explicit about whether we're putting brackets around an address.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This class uses the dynamic doctest discovery mechanism,
`test_Tests.generateTrialAdaptedDoctestSuite`, to run all discovered
doctests. The generated methodnames in this `TestCase` correspond to
location in the source code where the doctest was discovered.
It also (somewhat) magically manages to print exception/failure
tracebacks for failed doctests in a manner which is compatible with
twisted.trial. The printed tracebacks will tell you:
1. Where the doctest is, and which line caused the exception.
2. What the expected result was supposed to be (according to the
doctest), compared with what it actually was when the doctest code
was run.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is precisely the same as `test_Tests.OldUnittests`, except that it
re-runs all of the old unittests in lib/bridgedb/Tests.py with old code from
`bridgedb.test.deprecated` to assist in finding regressions.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is not *strictly* necessary; however, the previous manner that I
had devised for running the old unittests in lib/bridgedb/Tests.py had a
small problem: it ran *all* the tests in lib/bridgedb/Tests.py as a
single trial test. This meant that if a single test from Tests.py
failed, the whole test would fail, which doesn't give us very
fine-grained reporting, especially if there were multiple failures (the
whole thing would fail when the first one failed).
To fix that, it would be necessary to create one `TestCase` "test_*"
method per original unittest. Each individual unittest would also need
to be wrapped with a `twisted.trial.unittest.PyUnitResultAdapter`, in
order for twisted.trial to be able to capture tracebacks and
`failure.Failures` correctly. Additionally, it would be nice if we could
simply take each `TestCase` method from the original unittests and reuse
their method names (so that we know exactly which one of the original
unittests is being run); therefore, the methods need to be wrapped yet
again to reassign dynamic instancemethod names. (Normally, dynamically
mucking around with Python's namespace is a BadIdea™, but it turns out
not only that this works, but that it *also* works with the dynamically
discovered doctests from `test_Tests.generateTrialAdaptedDoctestSuite()`
as well!)
I mostly wanted to see if I could do it. Turns out, I can, and it seems
to work well. This black-magic encrusted monster I've munged together,
`DynamicTestCaseMeta`, works in the following manner:
1. It generates dynamic methodnames with a given `methodPrefix`
2. It generates corresponding methods for a
`twisted.trial.unittest.TestCase` base class.
3. Next, it wraps the generated methods. Sometimes, depending on the
base class, it wraps them multiple times. It also allows further
layers of wrapping, i.e. the `MonkeyPatcher` returned from
`monkeypatchTests()` still works.
4. Then, it assigns each generated methodname and method pair, using
the special __new__() constructor, to the base class *when the base
class is compiled* (i.e. when the test_Tests module is first
imported into a Python interpreter). Therefore, each time you
initialise a base class which uses `DynamicTestCaseMeta` as its
__metaclass__, every initialised instance will have the *same*
generated code, because the code which is generated is decided at
compile time, not access time.
* ADD the terrifying `test_Tests.DynamicTestCaseMeta` class generator.
post scriptum: Take that, C++! :P
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This function creates a `twisted.python.monkey.MonkeyPatcher` which will add
deprecated code from `bridgedb.test.deprecated` back in, so that a TestCase
class can run its tests on pre-refactored code to test for regressions.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This function discovers doctests within the directory that BridgeDB was
installed within, and then it builds a `twisted.trial.unittest.TestSuite` from
all discovered doctests.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* ADD `lib/bridgedb/test/deprecated.py` which contains old classes and
functions (before refactoring), so that they can be
`twisted.python.monkey.MonkeyPatched`ed into
`bridgedb.test.test_Tests` (and perhaps other tests). This causes the
unittests to function as regression tests when code is refactored, so
that (hopefully) we can find regression bugs faster.
In the future, we *should* be able to use `twisted.python.deprecate` to
deprecate function and classes in place (i.e. without removing them from
their original files). I didn't think to do this until long after these
had been removed, and re-adding deprecated code back into BridgeDB's
modules seems like it would be confusing.
That said, it is *also* fine, in the future, to actually move deprecated
code into `bridgedb.test.deprecated` (just make sure to change all
references to the original in the codebase!). However, doing this *does*
mean you'll need to do quite a bit more complicated monkeypatching in
`bridgedb.test.test_Tests.py`, or any other future regression
testsuites.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds a new unittest file, `lib/bridgedb/test/test_Tests.py`, which
runs the old unittests in `lib/bridgedb/Tests.py` with a unittest report
adapter that is compatible with twisted.trial. It uses the underlying
SynchronousTestCase wrapper for the stdlib `unittest.TestCase` (which
the tests in `lib/bridgedb/Tests.py` use).
* ADDS a trial runner for BridgeDB's old unittests.
* FIXES #9873
|
| |\ \ |
|
| | | | |
|
| |\ \ \
| |/ / |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | | |
* FIXES #10446
|
