Re: Turbogears2 migration: test suite

[Thomas De Schampheleire]

On Mon, Mar 28, 2016 at 10:09 PM, Thomas De Schampheleire
 wrote:
> Hi Alessandro,
>
> On Thu, Mar 17, 2016 at 9:17 AM, Alessandro Molina
>  wrote:
>>
>>
>> On Wed, Mar 16, 2016 at 10:26 PM, Thomas De Schampheleire
>>  wrote:
>>
>>>
>>> url used to come from pylons and is now tg.url.
>>> Has the signature changed?
>>
>>
>>
>> Yep, tg.url and pylons.url are pretty different, tg.url but has no concept
>> of controllers or actions as it's not bound to routes.
>> Try to use kallithea.lib.base.url in place of pylons.url I added that in a
>> past commit to replace pylons.url and should do what you expect.
>>
>
> I just pushed a new commit:
> https://bitbucket.org/_amol_/kallithea-tg/commits/6fc68d927062fc8e710002d8bfbb44601ef8206c
> which fixes the aforementioned 'url' issue.
>
> I was not able to use kallithea.lib.utils.url because it uses
> config['routes.url'] which did not seemed to be available at test
> time. Perhaps there is a better solution than the one I implemented,
> please suggest.
>
> As reported in another mail, there is an issue with routing after the
> introduction of tgext.routes, and I also just detected another issue
> in which I fail to make progress. I will send a separate mail for
> that.

In that issue I got 500 Internal Server Error without actual
backtrace. However, I just enabled debug mode and installed backlash,
and then I finally understood the issue and could fix it.

To check why there was no backtrace without debug mode.

Best regards,
Thomas
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Thomas De Schampheleire]

Hi Alessandro,

On Thu, Mar 17, 2016 at 9:17 AM, Alessandro Molina
 wrote:
>
>
> On Wed, Mar 16, 2016 at 10:26 PM, Thomas De Schampheleire
>  wrote:
>
>>
>> url used to come from pylons and is now tg.url.
>> Has the signature changed?
>
>
>
> Yep, tg.url and pylons.url are pretty different, tg.url but has no concept
> of controllers or actions as it's not bound to routes.
> Try to use kallithea.lib.base.url in place of pylons.url I added that in a
> past commit to replace pylons.url and should do what you expect.
>

I just pushed a new commit:
https://bitbucket.org/_amol_/kallithea-tg/commits/6fc68d927062fc8e710002d8bfbb44601ef8206c
which fixes the aforementioned 'url' issue.

I was not able to use kallithea.lib.utils.url because it uses
config['routes.url'] which did not seemed to be available at test
time. Perhaps there is a better solution than the one I implemented,
please suggest.

As reported in another mail, there is an issue with routing after the
introduction of tgext.routes, and I also just detected another issue
in which I fail to make progress. I will send a separate mail for
that.
I updated the wiki page at
https://bitbucket.org/conservancy/kallithea/wiki/Turbogears2Migration
to keep track of all issues.

Best regards,
Thomas
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Thomas De Schampheleire]

Hi Alessandro,

On Mon, Mar 14, 2016 at 11:39 PM, Alessandro Molina
 wrote:
> ok, not sure this is the way it should work, but now py.test
> kallithea/tests/other/test_dummy.py behave like expected.
>
>
> I used create_test_env  to properly setup the test environment and test DB:
>
> https://bitbucket.org/_amol_/kallithea-tg/src/21ba20204a4a55dd7744469b47e1d223b478/kallithea/tests/__init__.py?fileviewer=file-view-default#__init__.py-163
>
> Note that on my pc I had to comment some lines of create_test_env as it was
> failing due to file permissions, not sure this is only my problem:
>
> https://bitbucket.org/_amol_/kallithea-tg/src/21ba20204a4a55dd7744469b47e1d223b478/kallithea/lib/utils.py?fileviewer=file-view-default#utils.py-717:732


Thanks for looking into this. I can indeed run dummy_test now.

First observation however is that the database setup code is now run
at every test, while previously it was done once for the entire test
suite. I guess this is just a matter of moving the calls to the right
place.
(we know that it would be better to start with a fresh database each
time, but it takes a lot of time; we need to optimize this later).

Based on your commit, I think I now understand better the problem: in
pylons-based Kallithea, create_test_env was run from the
load_environment call, see
https://bitbucket.org/conservancy/kallithea/src/35508e2d755770b8ecfb25f72d218c3b837df9be/kallithea/config/environment.py?at=default=file-view-default#environment.py-105
This call has been removed with the current turbogears migration code.
Therefore, I think that to mimic the original behavior, we should fit
the call to create_test_env at approximately the same place in the
turbogears flow, I assume in setup_configuration in app_cfg.py.
Does this sound right to you?
I also assume that this would solve the first point above.

Thanks,
Thomas
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Alessandro Molina]

ok, not sure this is the way it should work, but now
py.test kallithea/tests/other/test_dummy.py behave like expected.


I used create_test_env  to properly setup the test environment and test DB:

https://bitbucket.org/_amol_/kallithea-tg/src/21ba20204a4a55dd7744469b47e1d223b478/kallithea/tests/__init__.py?fileviewer=file-view-default#__init__.py-163

Note that on my pc I had to comment some lines of create_test_env as it was
failing due to file permissions, not sure this is only my problem:

https://bitbucket.org/_amol_/kallithea-tg/src/21ba20204a4a55dd7744469b47e1d223b478/kallithea/lib/utils.py?fileviewer=file-view-default#utils.py-717:732

On Mon, Mar 14, 2016 at 1:41 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:

> Hi Alessandro,
>
> On Sun, Mar 13, 2016 at 10:10 PM, Alessandro Molina
>  wrote:
> >
> >
> > On Wed, Mar 9, 2016 at 8:09 PM, Thomas De Schampheleire
> >  wrote:
> >>
> >> Then I get an error that seems to indicate that the model is not
> >> correctly initialized.
> >
> >
> > I suppose you are mentioning the "no such table: permissions" error.
> > I faced that too.
> >
> > As I don't know much about the kallithea testsuite architecture and
> py.test
> > doesn't help as fixtures can come from anywhere, who should be in charge
> of
> > running the websetup and create the database? It seems to me that the
> issue
> > is just the no database is created. I saw a line mentioning setup-app in
> > test/__init__.py but it's commented.
>
> I must say that I'm also not very familiar with the setup part of the
> test suite.
> What I can say:
>
> - originally all setup was done in kallithea/tests/__init__.py
> - with the introduction of pytest, a new file
> kallithea/tests/conftest.py was added that does some setup. This code
> is run by pytest directly. This code has worked fine so far, allowing
> to run the test suite with 'py.test' rather than 'nosetests'.
>
> - recently, I have added TestControllerPytest in
> kallithea/tests/__init__.py to allow using real pytest features like
> fixtures. We are now in a transitional period where some tests are
> using the original TestController (unittest-based) and some tests are
> using the new TestControllerPytest.
> Due to the fact that pytest does not allow test classes to have a
> __init__ method, I had to reorganize and partially duplicate some
> setup code in kallithea/tests/__init__.py.
>
> We really care mostly about pytest style classes now. In parallel to
> the turbogears migration, I am converting the tests to
> TestControllerPytest, so soon this will be the only class remaining. I
> hope this can be completed too in the near future, so that by the time
> we can merge the Turbogears branch all tests are of a single (pytest)
> type.
>
> /Thomas
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Alessandro Molina]

On Wed, Mar 9, 2016 at 8:09 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:
>
> Then I get an error that seems to indicate that the model is not
> correctly initialized.


I suppose you are mentioning the "no such table: permissions" error.
I faced that too.

As I don't know much about the kallithea testsuite architecture and py.test
doesn't help as fixtures can come from anywhere, who should be in charge of
running the websetup and create the database? It seems to me that the issue
is just the no database is created. I saw a line mentioning setup-app in
test/__init__.py but it's commented.
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Alessandro Molina]

I'll try to give a try to test issues during the weekend, I promise :D
TurboGears 2.3.8 also got released so I can switch code to tgext.routes and
remove the need to pull from github.



On Wed, Mar 9, 2016 at 8:09 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:

> Hi Alessandro,
>
> On Wed, Feb 24, 2016 at 2:38 PM, Alessandro Molina
>  wrote:
> >
> >
> > On Fri, Feb 19, 2016 at 10:20 PM, Thomas De Schampheleire
> >  wrote:
> >>
> >> Currently the test initialization code has
> >> some pylons specifics which I don't understand (and thus fail to
> >> convert to a Turbogears equivalent).
> >>
> >> Essentially, the setup code in TestController is:
> >>
> >> self.wsgiapp = pylons.test.pylonsapp
> >> init_stack(self.wsgiapp.config)
> >> self.app = TestApp(self.wsgiapp)
> >>
> >> with init_stack being:
> >>
> >> def init_stack(config=None):
> >
> >
> > I didn't have time to look at it so far, sorry, but by a quick view of
> what
> > init_stack is doing it looks like it's mostly setting up the Pylons
> global
> > objects even when not inside a request. That should be fairly equivalent
> to
> > performing a request to '/_test_vars' in TurboGears or using
> >
> http://turbogears.readthedocs.org/en/latest/reference/classes.html#tg.util.webtest.test_context
> >
> > See
> >
> http://turbogears.readthedocs.org/en/latest/turbogears/testing.html#testing-outside-controllers
> > it might provide a few useful details.
> >
>
> So I've been spending quite some time in trying to get the test suite
> working but failed miserably.
> I looked at the references you sent, looked at the test suite of an
> example tg2 project, and tried to apply the same principles to our
> test suite, but I keep getting an error in the application setup.
>
> I created a dummy test that does not use the application itself, to
> verify the init code of the test suite, and try to run it with:
>
> $ py.test kallithea/tests/other/test_dummy.py
>
> Then I get an error that seems to indicate that the model is not
> correctly initialized.
> I tried adding traces to see what's going on, and tried many things,
> but could not get it to work.
> The fact that we're in a transition from nosetest to pytest does not
> really help either. In any case, the first focus is to getting the
> TestControllerPytest to work; I hope that soon all tests will be
> switched to it.
>
> In a separate mail I am sending the code I was last working with,
> along with the full error I'm seeing.
> If and when you have some time, could you have a look? Any help in
> progressing here is more than welcome!
>
> Thanks,
> Thomas
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Thomas De Schampheleire]

Hi Alessandro,

On Wed, Feb 24, 2016 at 2:38 PM, Alessandro Molina
 wrote:
>
>
> On Fri, Feb 19, 2016 at 10:20 PM, Thomas De Schampheleire
>  wrote:
>>
>> Currently the test initialization code has
>> some pylons specifics which I don't understand (and thus fail to
>> convert to a Turbogears equivalent).
>>
>> Essentially, the setup code in TestController is:
>>
>> self.wsgiapp = pylons.test.pylonsapp
>> init_stack(self.wsgiapp.config)
>> self.app = TestApp(self.wsgiapp)
>>
>> with init_stack being:
>>
>> def init_stack(config=None):
>
>
> I didn't have time to look at it so far, sorry, but by a quick view of what
> init_stack is doing it looks like it's mostly setting up the Pylons global
> objects even when not inside a request. That should be fairly equivalent to
> performing a request to '/_test_vars' in TurboGears or using
> http://turbogears.readthedocs.org/en/latest/reference/classes.html#tg.util.webtest.test_context
>
> See
> http://turbogears.readthedocs.org/en/latest/turbogears/testing.html#testing-outside-controllers
> it might provide a few useful details.
>

So I've been spending quite some time in trying to get the test suite
working but failed miserably.
I looked at the references you sent, looked at the test suite of an
example tg2 project, and tried to apply the same principles to our
test suite, but I keep getting an error in the application setup.

I created a dummy test that does not use the application itself, to
verify the init code of the test suite, and try to run it with:

$ py.test kallithea/tests/other/test_dummy.py

Then I get an error that seems to indicate that the model is not
correctly initialized.
I tried adding traces to see what's going on, and tried many things,
but could not get it to work.
The fact that we're in a transition from nosetest to pytest does not
really help either. In any case, the first focus is to getting the
TestControllerPytest to work; I hope that soon all tests will be
switched to it.

In a separate mail I am sending the code I was last working with,
along with the full error I'm seeing.
If and when you have some time, could you have a look? Any help in
progressing here is more than welcome!

Thanks,
Thomas
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: Turbogears2 migration: test suite

[Alessandro Molina]

On Fri, Feb 19, 2016 at 10:20 PM, Thomas De Schampheleire <
patrickdeping...@gmail.com> wrote:

> Currently the test initialization code has
> some pylons specifics which I don't understand (and thus fail to
> convert to a Turbogears equivalent).
>
> Essentially, the setup code in TestController is:
>
> self.wsgiapp = pylons.test.pylonsapp
> init_stack(self.wsgiapp.config)
> self.app = TestApp(self.wsgiapp)
>
> with init_stack being:
>
> def init_stack(config=None):


I didn't have time to look at it so far, sorry, but by a quick view of what
init_stack is doing it looks like it's mostly setting up the Pylons global
objects even when not inside a request. That should be fairly equivalent to
performing a request to '/_test_vars' in TurboGears or using
http://turbogears.readthedocs.org/en/latest/reference/classes.html#tg.util.webtest.test_context


See
http://turbogears.readthedocs.org/en/latest/turbogears/testing.html#testing-outside-controllers
it might provide a few useful details.
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general