looking for leads as to why Infusion Builder tests are failing.

Laurel A. Williams laurel.williams at utoronto.ca
Tue Nov 3 19:25:33 UTC 2009


Hi all,

Because I had a little Justin time available to me today, he showed me 
some investigations that he had done on this problem. I've posted the 
results here:
http://issues.fluidproject.org/browse/FLUID-3231

That is all I'm going to do on this task for now.

Laurel

Colin Clark wrote:
> Hi Laurel,
>
> On 27-Oct-09, at 11:44 AM, Laurel A. Williams wrote:
>
>> I'm trying to determine why I have some JS tests failing in the 
>> Infusion Builder and wondering if anyone has any leads to point me to 
>> the solution. In FireFox 3.5.3 on XP when the tests are run, a bunch 
>> of them (specifically 4, 5, 6, 12, 13, 14)  fail, but only on every 
>> second reload of the test page. In IE 8 on XP the tests fail (4, 5, 
>> 6, 12, 13, 14 and also 8, 16) all the time. This is peculiar enough 
>> to make me wonder in anyone else has seen anything similar.
>>
>> If you want to try the tests yourself, check out 
>> https://source.fluidproject.org/svn/incubator/custom-build/trunk/ and 
>> run infusion-builder/tests/html/customBuild-tests.html
>>
>> Thanks in advance for your thoughts.
>
>
> This didn't ring any bells for me, but I did take some time to trace 
> through your tests to learn more about what is going on. It looks 
> pretty clear to me that a call to jQuery UI's simulate() is failing 
> periodically.  The element you are trying to click on is definitely 
> there, it's just not correctly receiving the event. I'm seeing this, 
> for example, at line 404 of customBuild-tests.js.
>
> I'd like to hear more from others who know simulate() better than I 
> do. If necessary, an alternative approach is to programmatically 
> adjust the "checked" attribute on your checkboxes instead of 
> simulating click events.
>
> An aside, I found your tests really difficult to debug, due to the 
> strange way you've structured them. It looks like you committed a big 
> refactoring to these tests back at r7673, and I'm not sure it was 
> entirely for the best. By moving your test functions out into these 
> "generateXyz" functions on a "pseudo-that" called "testingFunctions," 
> you make it harder to set breakpoints in a specific test, rather than 
> for the general case of all similar tests. It also makes readability 
> more difficult. This feels to me like an attempt to remove repetitive 
> code, but at the wrong level of abstraction. I really like how 
> thorough all of these tests are, but I find it hard to quickly see the 
> difference between utility code, setup code, and the test bodies.
>
> At some point in the future, let's consider what it would take to 
> split up these tests into smaller units based. That said, I don't 
> think we want to invest the time in reworking these tests yet again 
> before we get the Builder released. It's something you'll probably 
> encounter yourself as you use Firebug to track down this issue, but 
> something that can wait for a bit.
>
> Hope this helps,
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurel_williams.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091103/b64452b6/attachment.vcf>


More information about the fluid-work mailing list