Unexpected hints for leave action in RPC ticket.getActions

[Olemis Lang]

Sometimes tracrpc.tests.ticket:RpcTicketTestCase.test_getActions in Trac>=1.0 fails because «The ticket will remain with no owner.» hint is returned by controller.render_ticket_action_control (controller => ConfigurableTicketWorkflow) for leave action (instead of empty string as expected) .

After reviewing the code of trac.ticket.default_workflow:render_ticket_action_control inconsistencies may be related to the fact that the number of operations for leave action may not be 1 under certain circumstances .

[Ryan J Ollos]

It sounds like it is related to the change in ​t:#11090/ ​[t 11778], but that change is scheduled for 1.0.2 so I wouldn't expect it would cause a problem for you in Trac <= 1.0.1.

[Olemis Lang]

Replying to rjollos:

It sounds like it is related to the change in ​t:#11090/ ​[t 11778], but that change is scheduled for 1.0.2 so I wouldn't expect it would cause a problem for you in Trac <= 1.0.1.

Maybe that's the reason why osimons cannot reproduce this issue ? In any case IMHO , something should be done to anticipate this test failure looking forward to Trac=1.0.2 . The failure is no big deal though ...

I'm running tests against relatively recent versions of branches in Trac source code i.e.

trunk => svn-11784 1.0-stable => svn-11783 0.12-stable => svn-11768 0.11-stable => svn-10236

This error is noticed in the first two cases mentioned above .

[osimons]

I was sure my mirror was up-to-date, but seems I was missing some recent changes. Now I see the error too. Fix coming shortly.

[osimons]

(In [13202]) XmlRpcPlugin: Fix tests after recent text changes in workflow action hints. Closes #11109.

[osimons]

Hmm. More worrying is the fact that latest 1.0.2dev now leaves a stray functional server process running after tests terminate. I need to kill it manually every time.

I see there has been a number of changes to functional infrastructure in Trac recently, and from the error message I get it seems we try to do too much at exit - and failing badly (this originates from inside the new-ish trac.util.terminate():

trac/util/__init__.py:319: RuntimeWarning: Parent module 'trac.util' \
                           not found while handling absolute import
  import os

I don't think we can depend on new imports succeeding at exit - we can hardly even depend on references to existing objects still being around... The new code works fine as tests run (start()/stop()/restart()), but I think trying to terminate self at exit needs to be shorter and simpler to succeed in a consistent manner. As we subclass this functional testenvironment, the lifecycle of this object is partly out of our hands.

[osimons]

(In [13203]) XmlRpcPlugin: Safer strategy for terminating functional test server. Refs #11109.

[osimons]

Following [13203] at least the server terminates consistently, but RuntimeWarning remains. However that is now just a Trac problem, and no longer a direct concern for the RPC plugin.

[Olemis Lang]

Replying to osimons:

Hmm. More worrying is the fact that latest 1.0.2dev now leaves a stray functional server process running after tests terminate. I need to kill it manually every time.

that happens to me sometimes running it inside PyDev . It's annoying , yes .

Nevertheless I find more worrying the fact that test cases are not isolated . I mean , if tickets and other stuff is not appropriately torn down then these might interfere with assertions in subsequent test cases , thus polluting test reports .

[...]

[Olemis Lang]

Replying to osimons:

Following [13203] at least the server terminates consistently, but RuntimeWarning remains. However that is now just a Trac problem, and no longer a direct concern for the RPC plugin.

I'll take a look into this , JIC ;)

[osimons]

Replying to olemis:

Nevertheless I find more worrying the fact that test cases are not isolated . I mean , if tickets and other stuff is not appropriately torn down then these might interfere with assertions in subsequent test cases , thus polluting test reports .

Correct. Let's keep it at 0 failures/errors and it won't be a problem ;-) As for the larger issue of fixing the functional test infrastructure we reuse, I think I'll leave that for another day...

[Olemis Lang]

Replying to osimons:

Replying to olemis:

Nevertheless I find more worrying the fact that test cases are not isolated . I mean , if tickets and other stuff is not appropriately torn down then these might interfere with assertions in subsequent test cases , thus polluting test reports .

Correct. Let's keep it at 0 failures/errors and it won't be a problem ;-) As for the larger issue of fixing the functional test infrastructure we reuse, I think I'll leave that for another day...

JFTR , in recent changesets committed onto ​this fork I've been trying an approach consisting in leaving 'some' traces of previous test case activity , but still keeping the test suite immune to previous noise . However that's partially possible due to the isolation provided by product environments i.e. there will be no interference among product data as long as unique prefixes will be allocated .

Maybe something similar may be done too in tracrpc.tests