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