Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Thu, 5 Nov 2015 12:32:02 -0500
"Jon A. Cruz"  wrote:

> 
> 
> On 11/05/2015 10:17 AM, Pekka Paalanen wrote:
> > On Fri, 16 Oct 2015 12:23:47 -0700
> > "Jon A. Cruz"  wrote:
> > 
> >> On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
> >>> I think it's better to land this stuff in pieces than massage a
> >>> humongous replace-the-world patch series, if we can tell the pieces are
> >>> going in the right direction. The bits here are mostly just following
> >>> the existing weston-test-client-helper.c (which the commit message
> >>> forgot to mention).
> >>>
> >>> But yeah, probably makes sense to see how hooking even this stuff up to
> >>> 'make check' would happen before landing this. That will be one of the
> >>> most interesting things here. This patch as is does not add anything to
> >>> 'make check' which is a little awkward for a series adding new test
> >>> code.
> >>>
> >>> As for writing tests in the mean time, people should just ignore the
> >>> new framework for now, and write tests as if it didn't exist as long as
> >>> it doesn't support what the old framework does.
> >>>
> >>> This way we can incrementally advance on both fronts at the same time.
> >>
> >> So, the immediate question would now be as to how I should stage things.
> >> Should the changes that will go into 'make check' be a separate patch
> >> set or should it be an additional patch in this set?
> >>
> >> I'd say that running it as a separate set might make juggling git a
> >> little easier on me. But not to a degree to outweigh what would make
> >> reviewing things easier.
> > 
> > Hi Jon,
> > 
> > as I'm not sure how you are going to hook things up to Weston and it
> > will be interesting to see how you do it, I would like to have it as a
> > part of this series adding waycheck. In my view, you can't even
> > demonstrate one without the other: waycheck needs a compositor, and
> > seeing how 'make check' starts a compositor for a test needs the test
> > client.
> > 
> > I would very much like to see both pieces at the same time, in case one
> > requires changes in the other. It would be nice to keep in mind all the
> > various test styles (client, module, ...) we listed in the past, so
> > that adding a new case later shouldn't cause a huge refactoring.
> > 
> > By test styles I mean basically the different cases in
> > tests/weston-tests-env script.
> > 
> 
> One aspect for waycheck is that it could be run against most any
> compositor at any time, so allowing for those uses makes it less of a
> driving factor and more of a client.

Right. However my point is, if waycheck doesn't run as part of 'make
check', likely no-one will run it. This is my major issue with the
waycheck patch.


Thanks,
pq

> The other tests, however, do need to start weston and with different
> configurations. Those then fall into the potential white-box testing
> world, while waycheck is more for black-box validation.
> 
> 
> I've been going through some general cleanup, but will include the some
> of the current 'make check' tests conversions also. Might take a little
> bit more, but we definitely want to keep things easiest to review.


pgpjTwiCoccdz.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Jon A. Cruz]

On 11/05/2015 10:17 AM, Pekka Paalanen wrote:
> On Fri, 16 Oct 2015 12:23:47 -0700
> "Jon A. Cruz"  wrote:
> 
>> On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
>>> I think it's better to land this stuff in pieces than massage a
>>> humongous replace-the-world patch series, if we can tell the pieces are
>>> going in the right direction. The bits here are mostly just following
>>> the existing weston-test-client-helper.c (which the commit message
>>> forgot to mention).
>>>
>>> But yeah, probably makes sense to see how hooking even this stuff up to
>>> 'make check' would happen before landing this. That will be one of the
>>> most interesting things here. This patch as is does not add anything to
>>> 'make check' which is a little awkward for a series adding new test
>>> code.
>>>
>>> As for writing tests in the mean time, people should just ignore the
>>> new framework for now, and write tests as if it didn't exist as long as
>>> it doesn't support what the old framework does.
>>>
>>> This way we can incrementally advance on both fronts at the same time.
>>
>> So, the immediate question would now be as to how I should stage things.
>> Should the changes that will go into 'make check' be a separate patch
>> set or should it be an additional patch in this set?
>>
>> I'd say that running it as a separate set might make juggling git a
>> little easier on me. But not to a degree to outweigh what would make
>> reviewing things easier.
> 
> Hi Jon,
> 
> as I'm not sure how you are going to hook things up to Weston and it
> will be interesting to see how you do it, I would like to have it as a
> part of this series adding waycheck. In my view, you can't even
> demonstrate one without the other: waycheck needs a compositor, and
> seeing how 'make check' starts a compositor for a test needs the test
> client.
> 
> I would very much like to see both pieces at the same time, in case one
> requires changes in the other. It would be nice to keep in mind all the
> various test styles (client, module, ...) we listed in the past, so
> that adding a new case later shouldn't cause a huge refactoring.
> 
> By test styles I mean basically the different cases in
> tests/weston-tests-env script.
> 

One aspect for waycheck is that it could be run against most any
compositor at any time, so allowing for those uses makes it less of a
driving factor and more of a client.

The other tests, however, do need to start weston and with different
configurations. Those then fall into the potential white-box testing
world, while waycheck is more for black-box validation.


I've been going through some general cleanup, but will include the some
of the current 'make check' tests conversions also. Might take a little
bit more, but we definitely want to keep things easiest to review.


-- 
Jon A. Cruz - Senior Open Source Developer
Samsung Open Source Group
j...@osg.samsung.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Fri, 16 Oct 2015 12:23:47 -0700
"Jon A. Cruz"  wrote:

> On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
> > I think it's better to land this stuff in pieces than massage a
> > humongous replace-the-world patch series, if we can tell the pieces are
> > going in the right direction. The bits here are mostly just following
> > the existing weston-test-client-helper.c (which the commit message
> > forgot to mention).
> >
> > But yeah, probably makes sense to see how hooking even this stuff up to
> > 'make check' would happen before landing this. That will be one of the
> > most interesting things here. This patch as is does not add anything to
> > 'make check' which is a little awkward for a series adding new test
> > code.
> >
> > As for writing tests in the mean time, people should just ignore the
> > new framework for now, and write tests as if it didn't exist as long as
> > it doesn't support what the old framework does.
> >
> > This way we can incrementally advance on both fronts at the same time.
> 
> So, the immediate question would now be as to how I should stage things.
> Should the changes that will go into 'make check' be a separate patch
> set or should it be an additional patch in this set?
> 
> I'd say that running it as a separate set might make juggling git a
> little easier on me. But not to a degree to outweigh what would make
> reviewing things easier.

Hi Jon,

as I'm not sure how you are going to hook things up to Weston and it
will be interesting to see how you do it, I would like to have it as a
part of this series adding waycheck. In my view, you can't even
demonstrate one without the other: waycheck needs a compositor, and
seeing how 'make check' starts a compositor for a test needs the test
client.

I would very much like to see both pieces at the same time, in case one
requires changes in the other. It would be nice to keep in mind all the
various test styles (client, module, ...) we listed in the past, so
that adding a new case later shouldn't cause a huge refactoring.

By test styles I mean basically the different cases in
tests/weston-tests-env script.


Thanks,
pq

PS. Sorry for disappearing, I cought a flu.


pgpt0I9_HVxMh.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Jon A. Cruz]

On 10/15/2015 01:51 AM, Pekka Paalanen wrote:
> I think it's better to land this stuff in pieces than massage a
> humongous replace-the-world patch series, if we can tell the pieces are
> going in the right direction. The bits here are mostly just following
> the existing weston-test-client-helper.c (which the commit message
> forgot to mention).
>
> But yeah, probably makes sense to see how hooking even this stuff up to
> 'make check' would happen before landing this. That will be one of the
> most interesting things here. This patch as is does not add anything to
> 'make check' which is a little awkward for a series adding new test
> code.
>
> As for writing tests in the mean time, people should just ignore the
> new framework for now, and write tests as if it didn't exist as long as
> it doesn't support what the old framework does.
>
> This way we can incrementally advance on both fronts at the same time.

So, the immediate question would now be as to how I should stage things.
Should the changes that will go into 'make check' be a separate patch
set or should it be an additional patch in this set?

I'd say that running it as a separate set might make juggling git a
little easier on me. But not to a degree to outweigh what would make
reviewing things easier.

-- 
Jon A. Cruz - Senior Open Source Developer
Samsung Open Source Group
j...@osg.samsung.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Wed, 14 Oct 2015 14:36:33 -0700
Bryce Harrington  wrote:

> On Wed, Oct 14, 2015 at 04:17:53PM +0300, Pekka Paalanen wrote:
> > On Wed,  7 Oct 2015 16:11:43 -0700
> > "Jon A. Cruz"  wrote:
> > 
> > > Adds an initial implementation of a testing tool that uses the unit
> > > test framework to run checks against an arbitrary Wayland compositor.
> > > Note that this is not intended for Weston-specific testing, but for
> > > generic Wayland testing.
> > > 
> > > Signed-off-by: Jon A. Cruz 
> > 
> > Hi Jon,
> > 
> > nice to see progress. :-)
> > 
> > I tested, waycheck runs fine if you run it manually. So this patch is
> > not even intended to hook it up to 'make check' at all, but just
> > compile a program you can run with any compositor?
> > 
> > When you later do hook things up into Weston's 'make check', will that
> > re-use the waycheck code or only the wayland_fixtures code?
> > 
> > I think the commit message should say which existing upstream tests
> > this patch reimplements. If it doesn't, it should say what we are
> > testing instead, in few words. Comments in waycheck.c could explain in
> > more detail about what is being tested.
> 
> Further, I am not sure we should land this until the test cases have
> been reimplemented to use it.  Having two test frameworks in the
> codebase increases complexity, and it's already tough to find folks to
> work on tests.

We are already past that, we already have two frameworks here.

I think it's better to land this stuff in pieces than massage a
humongous replace-the-world patch series, if we can tell the pieces are
going in the right direction. The bits here are mostly just following
the existing weston-test-client-helper.c (which the commit message
forgot to mention).

But yeah, probably makes sense to see how hooking even this stuff up to
'make check' would happen before landing this. That will be one of the
most interesting things here. This patch as is does not add anything to
'make check' which is a little awkward for a series adding new test
code.

As for writing tests in the mean time, people should just ignore the
new framework for now, and write tests as if it didn't exist as long as
it doesn't support what the old framework does.

This way we can incrementally advance on both fronts at the same time.


Thanks,
pq


pgp2ddjHBJ5rX.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Bryce Harrington]

On Wed, Oct 14, 2015 at 04:17:53PM +0300, Pekka Paalanen wrote:
> On Wed,  7 Oct 2015 16:11:43 -0700
> "Jon A. Cruz"  wrote:
> 
> > Adds an initial implementation of a testing tool that uses the unit
> > test framework to run checks against an arbitrary Wayland compositor.
> > Note that this is not intended for Weston-specific testing, but for
> > generic Wayland testing.
> > 
> > Signed-off-by: Jon A. Cruz 
> 
> Hi Jon,
> 
> nice to see progress. :-)
> 
> I tested, waycheck runs fine if you run it manually. So this patch is
> not even intended to hook it up to 'make check' at all, but just
> compile a program you can run with any compositor?
> 
> When you later do hook things up into Weston's 'make check', will that
> re-use the waycheck code or only the wayland_fixtures code?
> 
> I think the commit message should say which existing upstream tests
> this patch reimplements. If it doesn't, it should say what we are
> testing instead, in few words. Comments in waycheck.c could explain in
> more detail about what is being tested.

Further, I am not sure we should land this until the test cases have
been reimplemented to use it.  Having two test frameworks in the
codebase increases complexity, and it's already tough to find folks to
work on tests.

> More comments inline.
> 
> > ---
> >  .gitignore |1 +
> >  Makefile.am|   56 +-
> >  doc/doxygen/tooldev.doxygen.in |3 +-
> >  doc/doxygen/tools.doxygen.in   |6 +-
> >  tools/devtools.dox |   55 ++
> >  tools/tools.dox|   32 +
> >  tools/tools_arch_new.gv|   85 ++
> >  tools/tools_arch_old.gv|   53 ++
> >  tools/waycheck/rough_draw.c|  279 +++
> >  tools/waycheck/rough_draw.h|   49 ++
> >  tools/waycheck/waycheck.c  |  401 ++
> >  tools/waycheck/waycheck.dox|   29 +
> >  tools/wayland_fixtures/inc/wtst_fixtures.h |  263 +++
> >  tools/wayland_fixtures/src/wtst_fixtures.c | 1178 
> > 
> >  14 files changed, 2479 insertions(+), 11 deletions(-)
> >  create mode 100644 tools/devtools.dox
> >  create mode 100644 tools/tools.dox
> >  create mode 100644 tools/tools_arch_new.gv
> >  create mode 100644 tools/tools_arch_old.gv
> >  create mode 100644 tools/waycheck/rough_draw.c
> >  create mode 100644 tools/waycheck/rough_draw.h
> >  create mode 100644 tools/waycheck/waycheck.c
> >  create mode 100644 tools/waycheck/waycheck.dox
> >  create mode 100644 tools/wayland_fixtures/inc/wtst_fixtures.h
> >  create mode 100644 tools/wayland_fixtures/src/wtst_fixtures.c
> > 
> > diff --git a/.gitignore b/.gitignore
> > index 11d23da..7278bcf 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -106,4 +106,5 @@ weston.ini.5
> >  /tests/weston-ivi.ini
> >  internal-screenshot-00.png
> >  
> > +/waycheck
> >  /zuctest
> > diff --git a/Makefile.am b/Makefile.am
> > index 1900390..00cf9c7 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -972,7 +972,7 @@ endif
> >  #
> >  
> >  noinst_LTLIBRARIES += libshared.la libshared-cairo.la \
> > -   libzunitc.la libzunitcmain.la
> > +   libzunitc.la libzunitcmain.la libwayland-fixtures.la
> >  
> >  libshared_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
> >  
> > @@ -1011,6 +1011,22 @@ libshared_cairo_la_SOURCES = \
> > shared/frame.c  \
> > shared/cairo-util.h
> >  
> > +libwayland_fixtures_la_SOURCES = \
> > +   tools/wayland_fixtures/inc/wtst_fixtures.h  \
> > +   tools/wayland_fixtures/src/wtst_fixtures.c  \
> > +   shared/helpers.h
> > +
> > +libwayland_fixtures_la_CFLAGS = \
> > +   -I$(top_srcdir)/tools/wayland_fixtures/inc  \
> > +   -I$(top_srcdir)/tools/zunitc/inc\
> > +   $(TEST_CLIENT_CFLAGS)   \
> > +   $(AM_CFLAGS)
> > +
> > +libwayland_fixtures_la_LIBADD = \
> > +   $(TEST_CLIENT_LIBS) \
> > +   libzunitc.la\
> > +   libshared.la
> > +
> >  libzunitc_la_SOURCES = \
> > tools/zunitc/inc/zunitc/zunitc.h\
> > tools/zunitc/inc/zunitc/zunitc_impl.h   \
> > @@ -1028,8 +1044,8 @@ libzunitc_la_SOURCES = \
> > shared/helpers.h
> >  
> >  libzunitc_la_CFLAGS = \
> > -   $(AM_CFLAGS)\
> > -   -I$(top_srcdir)/tools/zunitc/inc
> > +   -I$(top_srcdir)/tools/zunitc/inc\
> > +   $(AM_CFLAGS)
> >  
> >  libzunitc_la_LIBADD = \
> > libshared.la
> > @@ -1045,8 +1061,8 @@ libzunitcmain_la_SOURCES = \
> > tools/zunitc/src/main.c
> >  
> >  libzunitcmain_la_CFLAGS = \
> > -   $(AM_CFLAGS)\
> > -   -I$(top_srcdir)/tools/zunitc/inc
> > +   -I$(top_srcdir)/tools/zunitc/inc\
> > +   $(AM_CFLAGS)
> 
> These two above hunks are a bit gratuitous. I suppose you want
> AM_CFLAGS to override specfici CFLAGS? Not 

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Wed,  7 Oct 2015 16:11:43 -0700
"Jon A. Cruz"  wrote:

> Adds an initial implementation of a testing tool that uses the unit
> test framework to run checks against an arbitrary Wayland compositor.
> Note that this is not intended for Weston-specific testing, but for
> generic Wayland testing.
> 
> Signed-off-by: Jon A. Cruz 

Hi Jon,

nice to see progress. :-)

I tested, waycheck runs fine if you run it manually. So this patch is
not even intended to hook it up to 'make check' at all, but just
compile a program you can run with any compositor?

When you later do hook things up into Weston's 'make check', will that
re-use the waycheck code or only the wayland_fixtures code?

I think the commit message should say which existing upstream tests
this patch reimplements. If it doesn't, it should say what we are
testing instead, in few words. Comments in waycheck.c could explain in
more detail about what is being tested.

More comments inline.

> ---
>  .gitignore |1 +
>  Makefile.am|   56 +-
>  doc/doxygen/tooldev.doxygen.in |3 +-
>  doc/doxygen/tools.doxygen.in   |6 +-
>  tools/devtools.dox |   55 ++
>  tools/tools.dox|   32 +
>  tools/tools_arch_new.gv|   85 ++
>  tools/tools_arch_old.gv|   53 ++
>  tools/waycheck/rough_draw.c|  279 +++
>  tools/waycheck/rough_draw.h|   49 ++
>  tools/waycheck/waycheck.c  |  401 ++
>  tools/waycheck/waycheck.dox|   29 +
>  tools/wayland_fixtures/inc/wtst_fixtures.h |  263 +++
>  tools/wayland_fixtures/src/wtst_fixtures.c | 1178 
> 
>  14 files changed, 2479 insertions(+), 11 deletions(-)
>  create mode 100644 tools/devtools.dox
>  create mode 100644 tools/tools.dox
>  create mode 100644 tools/tools_arch_new.gv
>  create mode 100644 tools/tools_arch_old.gv
>  create mode 100644 tools/waycheck/rough_draw.c
>  create mode 100644 tools/waycheck/rough_draw.h
>  create mode 100644 tools/waycheck/waycheck.c
>  create mode 100644 tools/waycheck/waycheck.dox
>  create mode 100644 tools/wayland_fixtures/inc/wtst_fixtures.h
>  create mode 100644 tools/wayland_fixtures/src/wtst_fixtures.c
> 
> diff --git a/.gitignore b/.gitignore
> index 11d23da..7278bcf 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -106,4 +106,5 @@ weston.ini.5
>  /tests/weston-ivi.ini
>  internal-screenshot-00.png
>  
> +/waycheck
>  /zuctest
> diff --git a/Makefile.am b/Makefile.am
> index 1900390..00cf9c7 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -972,7 +972,7 @@ endif
>  #
>  
>  noinst_LTLIBRARIES += libshared.la libshared-cairo.la \
> - libzunitc.la libzunitcmain.la
> + libzunitc.la libzunitcmain.la libwayland-fixtures.la
>  
>  libshared_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
>  
> @@ -1011,6 +1011,22 @@ libshared_cairo_la_SOURCES =   \
>   shared/frame.c  \
>   shared/cairo-util.h
>  
> +libwayland_fixtures_la_SOURCES = \
> + tools/wayland_fixtures/inc/wtst_fixtures.h  \
> + tools/wayland_fixtures/src/wtst_fixtures.c  \
> + shared/helpers.h
> +
> +libwayland_fixtures_la_CFLAGS = \
> + -I$(top_srcdir)/tools/wayland_fixtures/inc  \
> + -I$(top_srcdir)/tools/zunitc/inc\
> + $(TEST_CLIENT_CFLAGS)   \
> + $(AM_CFLAGS)
> +
> +libwayland_fixtures_la_LIBADD = \
> + $(TEST_CLIENT_LIBS) \
> + libzunitc.la\
> + libshared.la
> +
>  libzunitc_la_SOURCES = \
>   tools/zunitc/inc/zunitc/zunitc.h\
>   tools/zunitc/inc/zunitc/zunitc_impl.h   \
> @@ -1028,8 +1044,8 @@ libzunitc_la_SOURCES = \
>   shared/helpers.h
>  
>  libzunitc_la_CFLAGS = \
> - $(AM_CFLAGS)\
> - -I$(top_srcdir)/tools/zunitc/inc
> + -I$(top_srcdir)/tools/zunitc/inc\
> + $(AM_CFLAGS)
>  
>  libzunitc_la_LIBADD = \
>   libshared.la
> @@ -1045,8 +1061,8 @@ libzunitcmain_la_SOURCES = \
>   tools/zunitc/src/main.c
>  
>  libzunitcmain_la_CFLAGS = \
> - $(AM_CFLAGS)\
> - -I$(top_srcdir)/tools/zunitc/inc
> + -I$(top_srcdir)/tools/zunitc/inc\
> + $(AM_CFLAGS)

These two above hunks are a bit gratuitous. I suppose you want
AM_CFLAGS to override specfici CFLAGS? Not there is really anything
overridable. Or what's the reason for this?

>  
>  libzunitcmain_la_LIBADD =\
>   libzunitc.la\
> @@ -1305,7 +1321,7 @@ setbacklight_CFLAGS = $(AM_CFLAGS) 
> $(SETBACKLIGHT_CFLAGS)
>  setbacklight_LDADD = $(SETBACKLIGHT_LIBS)
>  endif
>  
> -all-local: zuctest$(EXEEXT)
> +all-local: waycheck$(EXEEXT) zuctest$(EXEEXT)
>  
>  noinst_PROGRAMS += zuctest$(EXEEXT)
>  
> @@ -1313,14 +1329,36 @@ zuctest_LDADD =   \

[PATCH weston] tests: Adding simple waycheck validation tool.

[Jon A. Cruz]

This is a follow-up breakout of the patches to add 'waycheck' for testing.

As the second of three submissions, this is one of the less interesting
except for the wtst_fixtures that can be reused elsewhere. A final
follow-up patchset will use the fixtures in a Weston-specific test program
that will include launching of Weston with different combinations of
modules for good white-box testing of Weston itself.

The waycheck tool focuses on more generic black-box testing, but might have
support added for a few extensions to access screenshots, etc. The intent
is for waycheck to be useful in the context of acceptance testing, while
leaving the third phase's submission to be useful for unit and/or
integration testing.

Jon A. Cruz (1):
  tests: Adding simple waycheck validation tool.

 .gitignore |1 +
 Makefile.am|   56 +-
 doc/doxygen/tooldev.doxygen.in |3 +-
 doc/doxygen/tools.doxygen.in   |6 +-
 tools/devtools.dox |   55 ++
 tools/tools.dox|   32 +
 tools/tools_arch_new.gv|   85 ++
 tools/tools_arch_old.gv|   53 ++
 tools/waycheck/rough_draw.c|  279 +++
 tools/waycheck/rough_draw.h|   49 ++
 tools/waycheck/waycheck.c  |  401 ++
 tools/waycheck/waycheck.dox|   29 +
 tools/wayland_fixtures/inc/wtst_fixtures.h |  263 +++
 tools/wayland_fixtures/src/wtst_fixtures.c | 1178 
 14 files changed, 2479 insertions(+), 11 deletions(-)
 create mode 100644 tools/devtools.dox
 create mode 100644 tools/tools.dox
 create mode 100644 tools/tools_arch_new.gv
 create mode 100644 tools/tools_arch_old.gv
 create mode 100644 tools/waycheck/rough_draw.c
 create mode 100644 tools/waycheck/rough_draw.h
 create mode 100644 tools/waycheck/waycheck.c
 create mode 100644 tools/waycheck/waycheck.dox
 create mode 100644 tools/wayland_fixtures/inc/wtst_fixtures.h
 create mode 100644 tools/wayland_fixtures/src/wtst_fixtures.c

-- 
2.1.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] tests: Adding simple waycheck validation tool.

[Jon A. Cruz]

Adds an initial implementation of a testing tool that uses the unit
test framework to run checks against an arbitrary Wayland compositor.
Note that this is not intended for Weston-specific testing, but for
generic Wayland testing.

Signed-off-by: Jon A. Cruz 
---
 .gitignore |1 +
 Makefile.am|   56 +-
 doc/doxygen/tooldev.doxygen.in |3 +-
 doc/doxygen/tools.doxygen.in   |6 +-
 tools/devtools.dox |   55 ++
 tools/tools.dox|   32 +
 tools/tools_arch_new.gv|   85 ++
 tools/tools_arch_old.gv|   53 ++
 tools/waycheck/rough_draw.c|  279 +++
 tools/waycheck/rough_draw.h|   49 ++
 tools/waycheck/waycheck.c  |  401 ++
 tools/waycheck/waycheck.dox|   29 +
 tools/wayland_fixtures/inc/wtst_fixtures.h |  263 +++
 tools/wayland_fixtures/src/wtst_fixtures.c | 1178 
 14 files changed, 2479 insertions(+), 11 deletions(-)
 create mode 100644 tools/devtools.dox
 create mode 100644 tools/tools.dox
 create mode 100644 tools/tools_arch_new.gv
 create mode 100644 tools/tools_arch_old.gv
 create mode 100644 tools/waycheck/rough_draw.c
 create mode 100644 tools/waycheck/rough_draw.h
 create mode 100644 tools/waycheck/waycheck.c
 create mode 100644 tools/waycheck/waycheck.dox
 create mode 100644 tools/wayland_fixtures/inc/wtst_fixtures.h
 create mode 100644 tools/wayland_fixtures/src/wtst_fixtures.c

diff --git a/.gitignore b/.gitignore
index 11d23da..7278bcf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -106,4 +106,5 @@ weston.ini.5
 /tests/weston-ivi.ini
 internal-screenshot-00.png
 
+/waycheck
 /zuctest
diff --git a/Makefile.am b/Makefile.am
index 1900390..00cf9c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -972,7 +972,7 @@ endif
 #
 
 noinst_LTLIBRARIES += libshared.la libshared-cairo.la \
-   libzunitc.la libzunitcmain.la
+   libzunitc.la libzunitcmain.la libwayland-fixtures.la
 
 libshared_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
 
@@ -1011,6 +1011,22 @@ libshared_cairo_la_SOURCES = \
shared/frame.c  \
shared/cairo-util.h
 
+libwayland_fixtures_la_SOURCES = \
+   tools/wayland_fixtures/inc/wtst_fixtures.h  \
+   tools/wayland_fixtures/src/wtst_fixtures.c  \
+   shared/helpers.h
+
+libwayland_fixtures_la_CFLAGS = \
+   -I$(top_srcdir)/tools/wayland_fixtures/inc  \
+   -I$(top_srcdir)/tools/zunitc/inc\
+   $(TEST_CLIENT_CFLAGS)   \
+   $(AM_CFLAGS)
+
+libwayland_fixtures_la_LIBADD = \
+   $(TEST_CLIENT_LIBS) \
+   libzunitc.la\
+   libshared.la
+
 libzunitc_la_SOURCES = \
tools/zunitc/inc/zunitc/zunitc.h\
tools/zunitc/inc/zunitc/zunitc_impl.h   \
@@ -1028,8 +1044,8 @@ libzunitc_la_SOURCES = \
shared/helpers.h
 
 libzunitc_la_CFLAGS = \
-   $(AM_CFLAGS)\
-   -I$(top_srcdir)/tools/zunitc/inc
+   -I$(top_srcdir)/tools/zunitc/inc\
+   $(AM_CFLAGS)
 
 libzunitc_la_LIBADD = \
libshared.la
@@ -1045,8 +1061,8 @@ libzunitcmain_la_SOURCES = \
tools/zunitc/src/main.c
 
 libzunitcmain_la_CFLAGS = \
-   $(AM_CFLAGS)\
-   -I$(top_srcdir)/tools/zunitc/inc
+   -I$(top_srcdir)/tools/zunitc/inc\
+   $(AM_CFLAGS)
 
 libzunitcmain_la_LIBADD =  \
libzunitc.la\
@@ -1305,7 +1321,7 @@ setbacklight_CFLAGS = $(AM_CFLAGS) $(SETBACKLIGHT_CFLAGS)
 setbacklight_LDADD = $(SETBACKLIGHT_LIBS)
 endif
 
-all-local: zuctest$(EXEEXT)
+all-local: waycheck$(EXEEXT) zuctest$(EXEEXT)
 
 noinst_PROGRAMS += zuctest$(EXEEXT)
 
@@ -1313,14 +1329,36 @@ zuctest_LDADD = \
libzunitc.la\
libzunitcmain.la
 
-zuctest_CFLAGS =   \
-   $(AM_CFLAGS)\
-   -I$(top_srcdir)/tools/zunitc/inc
+zuctest_CFLAGS =   \
+   -I$(top_srcdir)/tools/zunitc/inc\
+   $(AM_CFLAGS)
 
 zuctest_SOURCES =  \
tools/zunitc/test/fixtures_test.c   \
tools/zunitc/test/zunitc_test.c
 
+noinst_PROGRAMS += waycheck$(EXEEXT)
+
+waycheck_LDADD =   \
+   $(TEST_CLIENT_LIBS) \
+   libwayland-fixtures.la  \
+   libzunitcmain.la\
+   libshared.la
+
+waycheck_CFLAGS =  \
+   -I$(top_srcdir)/tools/zunitc/inc\
+   -I$(top_srcdir)/tools/wayland_fixtures/inc  \
+   -I$(top_builddir)/clients   \
+   -I$(top_srcdir)/shared  \
+   $(TEST_CLIENT_CFLAGS)   \
+   $(AM_CFLAGS)
+
+waycheck_SOURCES =