<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/10/8 Siqi Liu <span dir="ltr"><<a href="mailto:me@siqi.fr" target="_blank">me@siqi.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div dir="ltr">Hello all, <div><br></div></div></blockquote><div>Hi, <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
</div>
<div>I've been investigating on this issue and I've tried the patch from Julien and it still doesn't seem to fix the problem. There unit test always fails on the equality assertion even if we reverse that as well. </div>



<div><br></div><div>Here is what I've got: </div><div><br></div><div>When we check against sal_Int32(0xD99594) (i.e. 14259604 in decimal) for start color aGradient.StartColor <br></div><div><div>equality assertion failed</div>



<div>- Expected: 14259604</div><div>- Actual  : 12603469</div></div><div><br></div><div>and When we check against sal_Int32(0xC0504D) (i.e. 12603469 in decimal) for start color aGradient.StartColor</div><div><div>equality assertion failed</div>



<div>- Expected: 12603469</div><div>- Actual  : 14259604</div></div><div><br></div><div>That is, whenever we reverse the hex value (the expected value) for the unit test, the actual value coming out of the test is surprisingly reversed as well!! Which I failed to explain... </div>



<div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I have to assume that there are other filters that are tested against this unit test (which in this case needs to reverse the startColor/endColor as I have done in the ooxmlexport filter) or there are some hidden mechanism in this unit test that changes the actual value when we change the expected value... </div>



<div><br></div><div>My previous patch was tested (on OSX so without unit tests) during the Milano hackathon and it has solved an interoperability bug so presumbly we should keep this patch. Now I guess we need some qa experts to shed some light on the mechanism of this unit test ... </div>



<div><br></div><div><br></div></div></blockquote><div><br></div><div>I think the same way too. :) <br></div><div><br><div>Please someone correct [me/us] if [I'm/we are] wrong. I definitely have no idea 
how unit tests written :) This patch written 
on hackathon to solve a bug as Siqi said.<br><br>Tests are written according to the reversed start and 
end colors(Old code which we changed). After our change at hackathon 
expected value is wrong because test is written for the old code. So 
reversing the expected and given HEX values to test should cause 
reversed values. So maybe it means code is working as expected and the 
problem is test is written according to reversed values(old code) ?<br><br><br></div><div>(Good luck to understand the paragraph above :))</div> <br><br></div><div>Best,<br></div><div><br>--<br></div><div>Efe Gürkan YALAMAN<br>

</div></div><a href="http://about.me/efegurkan" target="_blank">http://about.me/efegurkan</a><br>
</div></div>