[Twisted-Python] Direct access to main server class

[Andrew Bennetts]

On Mon, Aug 28, 2006 at 10:31:37PM +0200, Terry Jones wrote:
[...]
> I could configure the unit tests to just use a different setup (different
> DB etc) so it has nothing to do with the server version. That's in fact
> what I used to do. I was mainly asking: now that I've built a nice new
> front door using twisted.cred, how do I convert my existing unit tests to
> all go through the door, changing as little as possible.

If you do that, they won't be *unit* tests any more, if I'm understanding your
structure correctly.

I'm guessing a significant proportion of your code you want to test, probably
the majority of it, has nothing directly to do with authentication or
permissions.  Also, *unit* tests (as opposed to functional tests or integration
tests or end-to-end tests or whatever other terms you prefer to use) test one
thing at a time, so tests for this code shouldn't also be testing
authentication.  If *every* test has to authenticate, then you're just wasting
effort: the tests run slower, there's more junk to step over in a debugger, and
you gain no extra testing value by testing the exact same thing in 50 (or
500...) different tests.

> >> 1) Fake it. Call directly into my code to make myself an authenticated
> >> user object, and then start passing it in to methods on my own
> >> class. This is ugly though, plus if the service is already running it's
> >> a bad solution because it goes behind the back of twisted and asks for
> >> trouble.
> 
> JP> This actually sounds a little like what I described above.  What makes
> JP> you say it is ugly?  To me, it sounds like organizing your code so that
> JP> you can test it a unit at a time.  The tests which do this are testing
> JP> the behavior of your code when authentication has already succeeded.
> JP> You should also have tests for your authentication code, of course -
> JP> but that's a separate unit.
> 
> It feels ugly in the way that Trial (if I understand it) feels right.
> There's an approved way to access the service, and robust tests should go
> through it. I don't fully believe this - I guess some combination, as you
> suggest, is probably going to be best. It feels ugly because, as I said,
> having built a new front door, I immediately hack my way around it.

No, it's quite common, and sensible, for tests to go directly to the units (i.e.
objects and methods) they want to test, so that they test precisely what they
should test.

> >> OK, sorry for another typically long posting....
> 
> JP> No problem.  I hope this was of some help.
> 
> Yes, it's great, thanks for answering. I feel like such a babe in the woods
> with Twisted! Part of it, I guess, is only really getting to work on this
> stuff when I'm not doing what I'm actually supposed to be doing.
> 
> Here's one more question, about cred. Given your initial comment and my
> emerging understanding of what goes on, what you call a user object
> (perhaps only because I called it that) is what's elsewhere called an
> avatar. If so, it seems an avatar can be anything at all and that generally
> an avatar is an instance of some class, and that that class has methods
> which the connecting user is allowed to call. I almost want to say "don't
> bother answering, I know I must be right", but I won't delete this
> paragraph just in case there are any other fundamental comments anyone
> might make.

"An avatar is a business logic object for a specific user. For POP3, it's a
mailbox, for a first-person-shooter it's the object that interacts with the
game, the actor as it were. Avatars are specific to an application, and each
avatar represents a single user."
    -- http://twistedmatrix.com/projects/core/documentation/howto/cred.html#auto6

(and also
http://twistedmatrix.com/projects/core/documentation/howto/glossary.html#Avatar,
which says basically the same thing).

So yes, your understanding is correct.

-Andrew.