Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 01 14:43
    brondsem closed #49
  • Aug 01 14:43

    brondsem on master

    add type annotation for update_… Fix double-patching issue that … test on python 3.10 and 3.11 and 1 more (compare)

  • Jul 29 22:00
    brondsem opened #49
  • Jul 15 16:51

    brondsem on master

    #39 remove a py2 __unicode__ me… (compare)

  • Jul 12 15:07
    Jackevansevo synchronize #22
  • Jun 30 16:26
    Jackevansevo synchronize #22
  • Jun 23 14:13
    Jackevansevo synchronize #22
  • Jun 23 14:13
    Jackevansevo synchronize #22
  • Jun 23 13:48
    Jackevansevo edited #22
  • Jun 23 13:46
    Jackevansevo edited #22
  • Jun 23 13:46
    Jackevansevo edited #22
  • Jun 23 13:44
    Jackevansevo edited #22
  • Jun 23 13:43
    Jackevansevo synchronize #22
  • Jun 23 13:41
    Jackevansevo edited #22
  • Jun 23 13:40
    Jackevansevo edited #22
  • Jun 23 13:39
    Jackevansevo opened #22
  • Jun 02 16:46
    brondsem closed #46
  • Jun 02 16:46

    brondsem on 0.12.0

    (compare)

  • Jun 02 16:46

    brondsem on master

    [#39] Removal of __future__ imp… [#39] pyupgrade --py37-plus run [#39] remove six dependency and 4 more (compare)

  • Jun 02 16:19

    brondsem on master

    helper to replace session - fro… test improvements - from #45 (compare)

Alessandro Molina
@amol-
Ok, I see what's going on
it's in setUp, so it means it's outside of any request. The transaction manager is not involved.
but super().setUp() does call setup-app which does commit the transaction that is using to initialize the database (see websetup/schema.py and websetup/bootstrap.py both of those commit a transaction)
as the transaction is global, you are reusing their transaction, but they arelady committed it
You need to change that code to be:
        try:
            u = model.User(user_name="what",email_address="what@where.whatever")
            model.DBSession.add(u)
        except:
            transaction.abort()
        else:
            transaction.commit()
every time you do something with DB outside of a turbogears request you need to manage the transaction on your own
As tests fixtures are not within a controller action called within a request, they are one of those cases where you need to manage on your own the transaction life.
@jknapka hope I addressed your doubts
Joe Knapka
@jknapka
@amol- Thank you... sorry I didn't reply sooner, it's 9AM here :-) I suspected it was something along these lines but I don't know sqlalchemy or the transaction module well enough to get to the bottom of it.
Yes, that totally works! Thank you!
Alessandro Molina
@amol-
:+1:
Joe Knapka
@jknapka
Hmm, still confused actually. If I create any DB entities inside my test methods, the same error occurs (unless I manually commit or abort the transaction). But test methods should be run inside a TG request and therefore with automatic transaction management, correct?
Alessandro Molina
@amol-
no
the test method is still outside of a TG reuqest
you would be running within a request if you did self.app.get(....) then that triggers request
otherwise in a test method you are not within an HTTP request
it's just a plain normal python function
so you need to commit the things youself
Joe Knapka
@jknapka
Ah! OK, thank you.
Joe Knapka
@jknapka
Hi! I'm having another testing problem. My test fixture creates a user in tg_user, then tries to load a page as that user in a test method, but authentication forging does not appear to work. The test method is annotated with @require(predicated.not_anonymous()) and the response from self.app.get("/the_url",extra_environ={'REMOTE_USER':'test_user'},response=200) is always a 401.
Also my code depends on being able to fetch the current tg_user object in order to generate the result page, but response.identity is None. How to handle this properly?
Nils Philippsen
@nphilipp
@jknapka how are you going at faking authenticated access?
Joe Knapka
@jknapka
According to the example code, it seems the extra_environ={"REMOTE_USER":"test_user"} argument to app.get() is supposed to do that, but maybe I misunderstand how this is intended to work.
(In other words by TG magic, I thought, but if I'm wrong I need to figure out how to do it right.)
Nils Philippsen
@nphilipp
Is the class in which your doing this derived from <project>.tests.TestController?
Joe Knapka
@jknapka
According to the quickstarted tests/init.py file, test suites should be run "with authentication disabled so that developers can test protected areas independently [of repoze.who]". Maybe that doesn't mean what I think it means.
Nils Philippsen
@nphilipp
I.e. you're modelling this after <project>.tests.functional.test_root?
Joe Knapka
@jknapka
Yes, exactly: I've copied test_root and am deriving from TestController.
Nils Philippsen
@nphilipp
Do the test_root tests succeed?
Joe Knapka
@jknapka
Yes.
Nils Philippsen
@nphilipp
Where are your tests located?
Joe Knapka
@jknapka
My other tests (that do not depend on particular user logins) also work fine.
project/tests/functional/test_blah.py
Nils Philippsen
@nphilipp
Hmm.
Where is your test_user created?
Ahh you mentioned it.
(Thinking aloud, I should stop that.)
Joe Knapka
@jknapka
In MyTestClass.setUp(). I can just paste the code here, although of course it won't run, but you could see the structure. It's only fifty lines or so. Shall I do that?
Nils Philippsen
@nphilipp
You could pastebin it somewhere.
E.g. as a github gist.
Joe Knapka
@jknapka
Hmm, actually it's a bit more complicated than it needs to be for clarity. I'll find a minimal reproducible case and post that somewhere in a little while.
Nils Philippsen
@nphilipp
I have a hunch that the tested method doesn't see the user because it's not committed to the DB or something similar.
Can you just pastebin the method that creates the user and adds it to the DB?
Joe Knapka
@jknapka
My "minimal reproduction" succeeds (unexpectedly), so I'm sure I'm missing something simple. I'll try to figure it out myself and post here again if I hit a brick wall. (You may very well be right about the DB issue, but I actually call the same utility method to create users in other test cases and that works. So I think it's something about how I've structured this specific test.)
Nils Philippsen
@nphilipp
Do the other test cases work against a test app, like the functional ones do?
Joe Knapka
@jknapka
Some do and some don't. I already figured out (from @amol_) that test fixtures and test cases that don't use a test app have to do manual transaction management, and I'm (probably!) handling that correctly :-D
Joe Knapka
@jknapka
Yep, my test fixture was raising an exception that was rolling back the txn! Thanks for the nudge in the right direction.
Nils Philippsen
@nphilipp
You're welcome!
Alessandro Molina
@amol-

@jknapka I suggest you verify the controller from which you are inheriting. There is a class attribute application_under_test (or something similar) that specified which configuration should be used to create the application instance used for the tests.

By default there are two applications configured in test.ini the main and mainnoauth (or something similar).

The noauth one supports faking authentication with the REMOTE_USER, while the other one requires you do to a self.app.post('/login_handler') to actually log before your can call authenticated endpoints

(It's main_without_authn the app name that accepts REMOTE_USER, just checked the name)