Zope.testbrowser query string

Plone Support Add-on Development
1

I'm having trouble passing a query string in a URL in my tests using the zope testbrowser (really plone.testing.zope.Browser). The test looks like this

self.browser.open(self.cf.absolute_url()+'?foobar=1')
self.assertIn('foobar', self.browser.contents)

And the page template is

<span tal:content="request/foobar|nothing">foobar</span>

That "foobar" parameter is not present in the template's request object though. I've verified I'm in the right template and if I remove the tal:content it works. Looking at the code I would still think that I should be able to pass a query string this way so I'm confused why it's failing. Is this the wrong way to call a url with GET parameters in tests?

2

Looks okay at first glance.

Can you try request/form/foobar|nothing instead?

Another thing to try is: temporarily remove the |nothing. Then you will get an error if foobar is not there, and maybe the error has a hint.

3

So I actually made a mistake in the above when trying to simplify. It should have been tal:condition, not tal:content. With tal:content obviously it replaces the inner span text with just "1". But I expected a value of "1" to make the tal:condition resolve true. Even weirder, if I include both a tal:content and a tal:condition neither work as expected.

Try with both a tal:content and a tal:condition

<span tal:content="request/foobar|nothing">foobar</span>
<span tal:condition="request/foobar|nothing">foobar</span>

Result:

<span></span>

It's almost like the tal:condition is popping the request variables for some reason. This is only a problem in the test browser, it works as expected on the site.

4

Eric Wohnlich via Plone Community wrote at 2022-12-21 21:23 +0000:

...
But I expected a value of "1" to make the tal:condition resolve true.

This should indeed be the case.

Try with both a tal:content and a tal:condition

foobar
foobar

Result:

It's almost like the tal:condition is popping the request variables for some reason.

This is impossible: the (template) rendering result is generated
sequencially: the later tal:condition cannot affect the former
tal:content.

By default, the chameleon template engine is used.
This compiles the template into Python byte code.
To save compilation time, it is using a cache.
In tests (long ago), I have seen cases where the cache has not been properly
invalidated after template changes -- and not the current template
was rendered, giving surprises.

You could try to determine whether your observation is caused
by the test browser or a wrong rendering.
I expect that your call uses ZPublisher.HTTPRequest.processInputs
to process the query string. You could put a (code) breakpoint
there, return and then examine self.form.
If it contains the correct foobar value, then the test browser
is not to blame.

When I remember right, the chameleon caching can be controlled
via an envvar (--> look at the documentation). You might want to disable
the caching to check whether the problem disappears.