Re: [E-devel] Introducing: elm_tsuite - a pixel comparison test suite for EFL.

[Cedric B. <ced...@fr...>]

On Tue, Jul 12, 2011 at 5:23 PM, Tom Hacohen
<tom...@pa...> wrote:
> On 12/07/11 18:11, Gustavo Sverzut Barbieri wrote:
>> It would be useful to have some references in SVN and also a tool to
>> diff these files, producing a hint on what's different other than pure
>> "cmp a b: files differ at byte X". This is done by WebKit, for
>> instance
> Well, it uses image magick to mark the different areas and also provides
> "old" and "new" images. I think it's more than enough to find out
> exactly what's wrong.
>>
>> Another useful idea from WebKit is the virtual dump of the render
>> tree. This walks the canvas, layers and objects (recursively) to
>> produce a textual output, that is then able to be diff'ed. This is
>> simpler to check and diff, also faster to run. Something like:
>>
>> Evas #123 100x100:
>>     Layer #456:
>>        Rectangle #1 @0,0 100x100 #ffffffff clipper=NONE
>> pass_events=TRUE repeat_events=FALSE visible=TRUE
>>        Image #2 @10,10 50x50 #ffffffff clipper=#1 pass_events=TRUE
>> repeat_events=FALSE visible=TRUE visible=TRUE border=2,2,2,2
>> scale_hint=STATIC file=bla key=NONE
>>        Smart #3 @0,0 100x100 #ffffffff clipper=NONE ...
>>           Rectangle #4 ...
>>           Text #5...
>>
>> The idea is to create virtual pointers (#1, #2...) so we can reference
>> them and diff the results in different runs.
>>
>
> That's a good idea, but a lot more annoying to implement than a simple
> script, and I'm not sure there's enough benefit to even bother.
>
> The test suite is aimed for developers that want to make sure they don't
> break something when they change it, and also for a testing server, and
> is intended to run along with all the other unit/regression/etc. tests.
> For the developers, saying there's a difference and marking it on a
> picture is usually more than enough, and for the testing server, this
> will just help us find issues and spot the problematic commits.
>
> But we will consider adding those features to the other testing tool,
> which will not be just a script launching binaries and will give us a
> lot more control.

Maybe using ensure to do this could help to ease the amount of work
required by this idea (that I really like to).
-- 
Cedric BAIL