[kforge-dev] Error in kforge trunk related to creation of trac service via web user interface

Mon Aug 28 19:34:19 UTC 2006

Rufus Pollock wrote:

> Regarding the tests I agree 100%. Of course here the problem lay in 
> the web gui which is the hardest thing to test (and that whose 
> functionality/interface changes most rapidly). Furthermore in this 
> case a test would involve stepping through several stages of the web 
> gui (login, go to project services page, create service, create 
> extension object). Nevertheless I was just looking at webunit of 
> (python) mechanize[1] to see if I could use them to automate the very 
> set of actions which resulted in this failure.

Out webunit code has three methods such methods.  See loginPerson(), 
registerProject(), deleteProject():

http://project.knowledgeforge.net/kforge/trac/browser/trunk/src/kforge/django/apps/kui/test/base.py

Sadly, that's as far as I got. But createTracService() could be the next 
addition! ;-)

<snip>

> Yes it was created. When I went back to the previous page the service 
> was there and I could delete it (and then could try again!)
>
>> An exception reporting the non-existence of the Service object would 
>> be sufficient documentation for this error. Perhaps this could 
>> usefully be in a getService() method on the ServiceExtnView.
>
>
> I don't think we necessarily need to document the error (that was 
> relatively easy to trace).

I simply meant it would be better if the TracProject code raised an 
excpetion when there isn't a service, which is always necessary for it 
(as you can't have TracProject objects without a Service object). But 
it's better if we has test to make sure the code gets the Service object....

> What was difficult to know was what the associationObject (which was 
> None) was supposed to be and where it should have been set. So, for 
> example, a short comment in the class docstring where 
> associationObject is first defined giving some information about its 
> purpose might be useful.

If we replace that comment with an exception, and then replace the 
exception with a test, we get to the idea I was suggesting.

>
>> I'll try to replicate the problem. Will let you know what happens.
>>
>> In the meantime, can you write a test to reveal this problem?
>
>
> Will try to (see above). Thanks for your detailed comments and 
> assistance in fixing this.

The best thing really is to have a test to make sure the ServiceExtnView 
receives a Service. It didn't because the method that was providing it 
was mistakenly demoted from the ServiceView to the ServiceReadView a 
short while ago. (We don't really need the webunit test for this, but it 
would be good to write it out. Another way of doing acceptance tests is 
with Ward's FIT framework. I've used it before and I think it would work 
well for us.)

Anyway, I did fix this problem by promoting the method back to the 
ServiceView (changeset 41), I think:

http://project.knowledgeforge.net/domainmodel/trac/changeset/41

Let me know if it works for you now?

Regards,

John.