Hi Damian,
Looking at coverage the test provides, I was under the impression that the
various cases of include_fields and exclude fields (e.g. if they overlap)
should also be tested, but if you find that unnecessary, that would help
explain why my unit tests were difficult to follow.
In the mocki
Hello,
I have created a ticket on Trac that links to the code on my github, which
is ready for a code review. This includes both TorExport
(stem/descriptor/export.py) which has already received a quick review and
the unit tests (test/unit/descriptor/export.py).
The ticket (#6512) can be found at
Hi Damian,
Here is a first draft for the tor export module we have been discussing. I
have attached the file as we were having some git issues and I am in a bit
of a rush right now. We have been developing the file at
stem/descriptors/export.py. Any suggestions or comments would be
appreciated
Hello,
Megan and I have been working on the CSV export functionality that was
being discussed a little over a week ago, and given the recent discussion,
we would like to clarify the expected/desired implementation of this
feature.
We have created an export.py module within /stem/descriptor, which
ry tor is using could easily have changed. Could you
give us some pointers on how we should approach these integration
tests?
Thank you in advance,
Erik & Megan
On 6/25/12, Erik I Islo wrote:
> Hi Damian,
>
> Megan and I have finished a first run at writing unit tests for the proc
&g
Hi Damian,
> In reading the following code I suspect that this could be clearer if
it accepted a single argument that was the dict of 'argument => return
value'.
All set -- mock_fn() now takes a dictionary rather than two lists as an
argument. The docstring suggestions have also been implemente
Hi Damian,
Megan and I have finished a first run at writing unit tests for the proc
utilities in stem. The code may be found on Megan's Github at:
https://github.com/meganchang/Stem/blob/proc-tests/test/unit/util/proc.py.
Until we hear back on a code review, we'll move on to the integration
tests
The way the os module seems to reference posix, I don't believe we will run
into any platform dependencies. Since os determines what environment it is
in then references either itself or an appropriate external module (such as
posix) in __dict__, it should always work.
With os.readlink, the issue
Hi Damian,
First, to clarify our github repository situation, both Megan and I will be
maintaining remote repos in github per Professor Danner's request so that
we each gain experience with version control systems. As we have been
working so far, I have been maintaining the mocking revisions in m
The changes look great! I see no issues with merging to the master branch.
Sorry about the reStructuredText inconvenience. I actually didn't even
think of it -- I just meant to clean up the comments a bit, but I'll
definitely be more careful in the future.
- Erik & Megan
On Thu, Jun 14, 2012 at 4
Hi Damian,
To answer your first question, we ran into the trouble when mocking
time.time(). This came up for us, as type(time.time) is
'builtin_function_or_method', which is the same as type(open) ->
'builtin_function_or_method'.
We also updated your adaptation to our patch so that no code is re
Hi Damian,
Having gotten started looking at some of the testing code from Stem over
the last day or so, Megan and I have come up with a question. While both
of us are currently on #tor and #tor-dev (as ErikI and MeganC), we figured
an email would be best for getting started as we have a bit more
12 matches
Mail list logo
