[Twisted-Python] Running unit tests without trial?

[Russell E. Owen]

Is it possible to run twisted.trial unit tests using python instead of 
trial, i.e.: "python mytest.py" instead of  "trial mytest.py"?

I'm hoping there is some simple magic I can put into the unit test 
itself to make this work. Perhaps something in
if __name__ == "__main__":
   ...?
to make it start up the reactor and run it correctly.

I ask because I'm using a build environment that runs all unit tests 
this way. It does the sniffing out and the saving of logs, but it 
insists on running .py tests using python.

-- Russell

P.S. being *able* to run trial unit tests using python seems like a 
feature to me in any case -- one I'd be willing to add extra code to 
support. Trial has some nice features, but I find it confusing that it 
is *required* to run a single test with a ".py" extension when visually 
it looks like a python file.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Running unit tests without trial?

[exarkun]

On 06:15 pm, ro...@uw.edu wrote:

Is it possible to run twisted.trial unit tests using python instead of
trial, i.e.: "python mytest.py" instead of  "trial mytest.py"?


Sure.  Here's the worst case answer (contents of mytest.py):

   import os
   os.system("trial myrealtests.py")

By the way, it's usually better to use the FQPN to run tests - not the 
filename.  Using the filename exposes you to all kinds of gross edge 
cases that trial doesn't always handle very well (having to do with how 
modules are loaded in Python).  So consider this instead:


   trial mytest

Or better yet, since you should be distributing and installing your test 
suite along with your package:


   trial myproject.test

There *are* better ways than `os.system´ to get a runnable Python source 
file that will run your tests though.


One that shouldn't be much of a surprise is to do exactly what you would 
do for a stdlib unittest-based test module:


   if __name__ == '__main__':
   import unittest
   unittest.main()

Or you can just invoke the same code that the command line trial script 
invokes:


   from twisted.scripts.trial import run
   run()

(That's not exactly the same as /usr/bin/trial, but you can read 
/usr/bin/trial to see the differences if you're interested).


Jean-Paul


I'm hoping there is some simple magic I can put into the unit test
itself to make this work. Perhaps something in
if __name__ == "__main__":
  ...?
to make it start up the reactor and run it correctly.

I ask because I'm using a build environment that runs all unit tests
this way. It does the sniffing out and the saving of logs, but it
insists on running .py tests using python.

-- Russell

P.S. being *able* to run trial unit tests using python seems like a
feature to me in any case -- one I'd be willing to add extra code to
support. Trial has some nice features, but I find it confusing that it
is *required* to run a single test with a ".py" extension when visually
it looks like a python file.


For what it's worth, just having a ".py" extension doesn't mean a file 
is intended to be run directly.  In fact, the vast majority of ".py" 
files are not intended to be run directly.  For example, out of the 816 
".py" files that are part of Twisted, probably only a handful are meant 
to be run directly.


What the ".py" extension unquestionably means is "this is a python 
module, it can be imported".  Arguably command line entrypoints should 
not have a ".py" extension - just as command line tools written in C and 
compiled to some version of native don't have a ".a" or ".so" extension 
(let alone a ".c" extension).


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Sprint Report (2013-09-23)

[Glyph]

On Sep 24, 2013, at 1:39 PM, Richard Wall  wrote:

> On 24 September 2013 14:07,   wrote:
> 
>> Woo.  Hope you guys had fun.  Thanks for the report, Richard.
> 
> Yep, it was a good day.
> 
> There were a few things that could have gone better. Here are a few thoughts.

Thanks for writing this up.  It's always good to get better at sprints, and 
someone taking the time to take note of what went right and what went wrong.

> * Easy Tickets
> In hindsight, I should have prepared a selection of suitable tickets.

It seems like we learn this lesson every time :-).

However, I think that one reason that this always comes up is that preparing 
that selection of suitable tickets is a challenging task in its own right, that 
someone (or a group of people) needs to set aside time for.

> The "easy" tickets search is useful, but many of them have been worked
> on already and it's difficult to choose which of these are suitable
> for sprint contributors without reading through the history.

The "easy" ticket search is always like this because every 'easy' ticket needs 
to have its keyword status re-evaluated after every single bit of work that is 
done on it; every review, every commit, every patch; maybe even every bug 
comment.

Does anyone want to start an "easy team" that just keeps tabs on this list and 
tries to keep it updated? :)

> One of the tickets I chose had already been mostly completed and the
> remaining work (filling in missing docstrings for mail avatar tests)
> was impossible for me to explain, let alone for the new contributors.

This is one reason why we should be encouraging people to write docs first, 
along with writing tests first :).  Once there's an implementation that needs 
to be explained, bugs start to bottleneck on the original author.  But if 
there's just an explanation that needs to be implemented, it's generally easier 
for more people with different levels of skill to jump in.

> The "documentation" ticket report is also useful, but with our current
> version of trac, there's no way of dynamically creating a report which
> looks for "easy" AND "documentation" keywords. 

You can sort of half-ass it by searching for 'easy documentation' or 
'documentation easy' :-).  That'll get you some results, although obviously not 
every possible combination.

> New versions of trac allow this I think.

I've filed a ticket asking for someone to upgrade Trac, but at this point we 
have pretty much no concrete reasons to do so.  If you have specific features 
in new versions that would be helpful, it would be good to collect them here:



> Meanwhile we could write a custom SQL report for this. And again it requires 
> a little preparation to select tickets which haven't got complications.

Presumably the "tickets which haven't got complications" work is covered by 
curating the "easy" keyword?

> * Windows Development
> Two of the guys were running windows and I struggled to help them set
> up a working development environment. This evening I found this page
> by cyli which might have helped, but probably needs updating.
> * https://twistedmatrix.com/trac/wiki/TwistedDevelopment#Win32development

This already has been updated; a newer version is here:

http://blog.ying.li/2012/03/twisted-development-on-windows-v2.html

But even that still needs updating :-\.

> * Working in pairs
> Anyway, we soon gave up on Windows and they paired up with the others
> who were running Linux, and that worked well.

Sad that the Windows people didn't get a good environment that they could take 
home, but hey, if they take the lesson that Windows is a mistake that causes 
them pain, so much the better ;-).

But, all kidding aside, we could really use more contributors who use Windows 
and can give a different perspective on it.  If people are going to write 
Windows software - and it seems like we can't stop them - it would be nice if 
they used Twisted for it.  (And they are not going to make the decision that 
Windows causes them pain; they are going to decide that either Twisted or 
Python does.)

> * Dev Requirements
> It would be nice to have a dev-requirements.txt file so that they
> could easily install the necessary development tools. pydoctor,
> coverage, nevow, zope.interface, twistedchecker, etc
> See:
> * https://github.com/hynek/structlog/blob/master/dev-requirements.txt

What tools actually make use of this file?  Why is it desirable to keep this 
information there, instead of the 'requirements' key in setup.py?  (Is there a 
'develop_requires' key?)

> * Nevow
> One of the guys was trying to run the documentation tools and we all
> got thoroughly confused by the many broken links to Nevow.
> 
> The official link is
> https://launchpad.net/divmod.org
> ...but it doesn't include a link to documentation.
> 
> There are these unofficial links and yet these are linked to from the
> Twisted docs.
> https://launchpad.net/divmod
> https://launchpad.ne

Re: [Twisted-Python] Running unit tests without trial?

[Julian Berman]

On Wed, 25 Sep 2013 18:45:44 - exar...@twistedmatrix.com wrote:
> On 06:15 pm, ro...@uw.edu wrote:
> >Is it possible to run twisted.trial unit tests using python instead of
> >trial, i.e.: "python mytest.py" instead of  "trial mytest.py"?
>
> Sure.  Here's the worst case answer (contents of mytest.py):
>
> import os
> os.system("trial myrealtests.py")

There is also http://twistedmatrix.com/trac/ticket/4797

Cheers,
Julian
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Running unit tests without trial?

[Russell E. Owen]

In article <20130925184544.26068.1404349410.divmod.xquotient.2424@top>,
 exar...@twistedmatrix.com wrote:

> On 06:15 pm, ro...@uw.edu wrote:
> >Is it possible to run twisted.trial unit tests using python instead of
> >trial, i.e.: "python mytest.py" instead of  "trial mytest.py"?
> 
> Sure.  Here's the worst case answer (contents of mytest.py):
> 
> import os
> os.system("trial myrealtests.py")
> 
> By the way, it's usually better to use the FQPN to run tests - not the 
> filename.  Using the filename exposes you to all kinds of gross edge 
> cases that trial doesn't always handle very well (having to do with how 
> modules are loaded in Python).  So consider this instead:
> 
> trial mytest
> 
> Or better yet, since you should be distributing and installing your test 
> suite along with your package:
> 
> trial myproject.test
> 
> There *are* better ways than `os.system´ to get a runnable Python source 
> file that will run your tests though.
> 
> One that shouldn't be much of a surprise is to do exactly what you would 
> do for a stdlib unittest-based test module:
> 
> if __name__ == '__main__':
> import unittest
> unittest.main()

I am surprised it works because I had already tried:

from twisted.trial import unittest
...
if __name__ == '__main__':
twisted.trial.unittest.main()

but twisted.trial.unittest has no main function (a rude surprise), so it 
never occurred to me that the built-in unittest library's main would 
work.

It seems to be exactly what I want.

> Or you can just invoke the same code that the command line trial script 
> invokes:
> 
> from twisted.scripts.trial import run
> run()

I tried that as well, but as you say, it is acting as if it was started 
by trial, so it prints help and quits. I guess it wants some arguments.  
I'm sure it'd be useful for some use cases, but for mine your first 
suggestion looks perfect.

Many thanks.

-- Russell


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Sprint Report (2013-09-23)

[Hynek Schlawack]

>> * Dev Requirements
>> It would be nice to have a dev-requirements.txt file so that they
>> could easily install the necessary development tools. pydoctor,
>> coverage, nevow, zope.interface, twistedchecker, etc
>> See:
>> * https://github.com/hynek/structlog/blob/master/dev-requirements.txt
> 
> What tools actually make use of this file?  

pip install -r dev-requirements.txt

> Why is it desirable to keep this information there, instead of the 
> 'requirements' key in setup.py?

There is no ‘requirements’ key – and ‘requires’ are runtime dependencies.  You 
don’t want to put your development tools there.

>   (Is there a 'develop_requires' key?)

No: 
http://pythonhosted.org/distribute/setuptools.html#new-and-changed-setup-keywords

There is tests_require which is also something different from development tools 
and get used when you run setup.py test which we AFAIK don’t.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] (no subject)

[Daniel Sank]

Dear Twisted users,

I recently found myself implementing a design pattern that I think
twisted.pb was specifically designed to address. I think I'm not using pb
correctly so I'd like advice. This is a somewhat longish post because I
need to describe the problem I'm trying to solve.

I have done internet searches on Stack Overflow and this list but have not
found the answer to my question. If I've missed something kindly direct me
to the appropriate reference.

I want to implement something functionally equivalent to a network chess
game. I first consider how I would do this on a single computer with no
network (maybe this is bad thinking). Each piece in the game is represented
by an instance of class Agent. Each agent has a .graphics attribute which
is an instance of a class from a GUI toolkit library or equivalent.
Whenever an agent in the game needs to do something there will be business
logic executed by the game objects proper (ie the agents) which will invoke
methods on the .graphics objects to update the screen. This sort of
structure seems natural as it allows easy integration of drag/drop, mouse
click detection etc. It also nicely separates the real business logic from
the GUI.

Now I want to run over the network. The question is how should I set up
references between the client and server objects?

Surely the server will maintain a set of objects representing the pieces in
the game. It seems reasonable that each user's program will have a
corresponding set of objects (with .graphics attributes). The issue is,
what do we mean by "corresponding" and how do these objects talk to one
another? Following is my idea so far:

Each instance of AgentClient has a .server attribute which is a remote
reference to an instance of AgentServer, and each instance of AgentServer
has a .clients attribute which is a list of remote references to instances
of AgentClient.

class AgentServer(pb.referenceable):

def remote_move(self, targetSquare):
"""Handle move request from client"""
if self.thisMoveIsLegal(targetSquare):
self.position = targetSquare
for client in self.clients:
client.callRemote("move", targetSquare)

def thisMoveIsLegal(self, targetSquare):


class AgentClient(pb.referenceable):

def requestMove(self, targetSquare):
"""Tell server we'd like to move"""
self.server.callRemote("move", targetSquare)

def remote_move(self, targetSquare):
"""Server told us we moved"""
self.position = targetSquare
self.graphics.setNewPosition(targetSquare)

This isn't THAT bad. The client's requestMove is thin and unecessary (I put
it there for illustration). Still I need to have two separate classes with
corresponding methods to handle moving the piece. This seems like the kind
of thing I could twisted.pb to solve more cleanly if I only would look in
the right place.

This problem gets even worse when I think about how to birth new in-game
objects. It would have to look like this:

class PlayerServer(pb.referenceable):

def newAgent(self, asker):
"""Client told us it wants a new Agent"""
if self.thisIsLegal():
a = AgentServer()
self.agents.append(a)
for client in self.clients:
d = client.callRemote("newAgent", a)
d.addCallback(lambda obj: a.clients.append(obj))

class PlayerClient(bp.referenceable):

def requestNewAgent(self):
"""Tell the server we want to spawn a new Agent"""
self.server.callRemote("newAgent", self)

def newAgent(self, serverObj):
a = AgentClient()
self.agents.append(a)
a.server = serverObj
return a

This just looks wrong. Any advice?

Thank you in advance for your help.

Regards,
Daniel Sank
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Clean pb solution for two-way object sync?

[Daniel Sank]

(Apologies for double send but I forgot the subject line)

Dear Twisted users,

I recently found myself implementing a design pattern that I think
twisted.pb was specifically designed to address. I think I'm not using pb
correctly so I'd like advice. This is a somewhat longish post because I
need to describe the problem I'm trying to solve.

I have done internet searches on Stack Overflow and this list but have not
found the answer to my question. If I've missed something kindly direct me
to the appropriate reference.

I want to implement something functionally equivalent to a network chess
game. I first consider how I would do this on a single computer with no
network (maybe this is bad thinking). Each piece in the game is represented
by an instance of class Agent. Each agent has a .graphics attribute which
is an instance of a class from a GUI toolkit library or equivalent.
Whenever an agent in the game needs to do something there will be business
logic executed by the game objects proper (ie the agents) which will invoke
methods on the .graphics objects to update the screen. This sort of
structure seems natural as it allows easy integration of drag/drop, mouse
click detection etc. It also nicely separates the real business logic from
the GUI.

Now I want to run over the network. The question is how should I set up
references between the client and server objects?

Surely the server will maintain a set of objects representing the pieces in
the game. It seems reasonable that each user's program will have a
corresponding set of objects (with .graphics attributes). The issue is,
what do we mean by "corresponding" and how do these objects talk to one
another? Following is my idea so far:

Each instance of AgentClient has a .server attribute which is a remote
reference to an instance of AgentServer, and each instance of AgentServer
has a .clients attribute which is a list of remote references to instances
of AgentClient.

class AgentServer(pb.referenceable):

def remote_move(self, targetSquare):
"""Handle move request from client"""
if self.thisMoveIsLegal(targetSquare):
self.position = targetSquare
for client in self.clients:
client.callRemote("move", targetSquare)

def thisMoveIsLegal(self, targetSquare):


class AgentClient(pb.referenceable):

def requestMove(self, targetSquare):
"""Tell server we'd like to move"""
self.server.callRemote("move", targetSquare)

def remote_move(self, targetSquare):
"""Server told us we moved"""
self.position = targetSquare
self.graphics.setNewPosition(targetSquare)

This isn't THAT bad. The client's requestMove is thin and unecessary (I put
it there for illustration). Still I need to have two separate classes with
corresponding methods to handle moving the piece. This seems like the kind
of thing I could twisted.pb to solve more cleanly if I only would look in
the right place.

This problem gets even worse when I think about how to birth new in-game
objects. It would have to look like this:

class PlayerServer(pb.referenceable):

def newAgent(self, asker):
"""Client told us it wants a new Agent"""
if self.thisIsLegal():
a = AgentServer()
self.agents.append(a)
for client in self.clients:
d = client.callRemote("newAgent", a)
d.addCallback(lambda obj: a.clients.append(obj))

class PlayerClient(bp.referenceable):

def requestNewAgent(self):
"""Tell the server we want to spawn a new Agent"""
self.server.callRemote("newAgent", self)

def newAgent(self, serverObj):
a = AgentClient()
self.agents.append(a)
a.server = serverObj
return a

This just looks wrong. Any advice?

Thank you in advance for your help.

Regards,
Daniel Sank
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python