[PATCH weston] Added simple unit/integration test framework and corresponding test program.

[Pekka Paalanen]

On Tue, 05 May 2015 15:54:34 -0700
"Jon A. Cruz" <jonc at osg.samsung.com> wrote:

> On 05/05/2015 09:40 AM, Jon A. Cruz wrote:
> > 
> > 
> > I'll move forward with merging things together. At the moment there is
> > some general testing work that others have outstanding, so I'll hold off
> > on modifying the existing files. Most likely some will just take
> > migrating appropriate functionality to the separated files.
> > 
> > One thing I have pending on docs are quick diagrams of the current code
> > organization and a proposed end state. Those should be sent out soon for
> > additional info and review.
> > 
> 
> 
> I've submitted a slightly updated patch that mainly adds the mentioned
> docs. To help avoid the need to run doxygen to generate them I'm
> attaching the diagrams directly here.

Hi Jon,

nice pics!

My take-away with these is that you are separating weston-specific
tests from compositor-agnostic tests. I think that is excellent.

So far you have been looking at:
- unit tests 'ish (vertex-clip-test.c)
- generic client tests (subsurface-test.c)
- weston-specific client tests (devices-test.c)

Unit tests are just plain executables. Client tests require Weston to
be running with desktop-shell.

If you look at tests/weston-tests-env script, you see more test types
not mentioned above:
- weston plugin tests (surface-global-test.c)
- client tests requiring ivi-shell (ivi-shell-app-test.c)
- weston plugin tests requiring ivi-shell (ivi_layout-internal-test.c)
- weston plugin tests requiring ivi-shell and a client
  (ivi_layout-test.c + ivi_layout-test-plugin.c)

So we have lots of different types of tests, each requiring a specific
runtime setup: run weston or not, which shell, is it a plugin or a
client, does the client need weston test extension...

Getting all these organized somehow would be cool. What do I mean by
that? I'm not sure. The current system just feels quite messy. Bryce
was trying to bring some order in weston-tests-env, but I think the
attempt I last looked went slightly overboard from another side.

This is not a wish for some sort of new "test specification language"
with which you can express oceans and the Moon, but a call for some
better structure. ;-)

So, maybe take this as more like a note, that we have many kinds of
tests with different runtimes.

I do have one wish: making it easy to run a test in gdb. That has
problems like choosing which process you want to attach gdb to, since
usually there are at least the compositor and the test client. Also,
how do you get gdb in there; start the process in gdb, or maybe add a
raise(SIGSTOP) on some conditions so gdb can attach "from outside".

That's just a brain dump of the moment. :-)


Thanks,
pq