[yocto] oe-selftest proof of concept

[Stoicescu, CorneliuX]

Hello,

After a chat with Richard and Stefan, I came up with an outline of how the oe-selftest feature(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4740 ) should look like. I made a summary of my proposal below. Please feel free to add your thoughts!

There will be a new script introduced(similar to bitbake-selftest) that will use python unit test to execute tests. Name has not been decided but it can be "oe-selftest".
Running this script will not compromise poky in any way.
Initially, the script does not need any preparation in order to be run. If this changes in the future, the user will be prompted upon execution with the pre-required tasks.
Oe-selftest can be used together with the automated runtime tests if necessary.

The following types of tests are targeted for the initial implementation:
- testing the functionality of scripts in poky/scripts (such as: bitbake-layers, yocto-bsp, yocto-kernel, yocto-layers)
- testing of the 'bitbake' command and its output (this includes output data validation such as the sstate-cache/ and tmp/ directories)

In order to achieve the above, the script will need to:

-          manipulate configuration files and variables

-          issue commands in a certain order

-          analyze command output

-          analyze output files and directories

-          manage shared resources such as sstate-cache

Oe-selftest will use Python Unit Testing as follows:
                - we will use what has already been done with the 'unittest' and 'oeqa' classes. This includes 'decorators' and methods like 'skipModules'.
                - the tests configuration files will be similar to those of the automated runtime tests.
                - because we are using the same framework and structure, the output will also be similar to that of the automated runtime tests
                - the build environments used will be set up in the setUpClass() or setUpModule() methods
                                * local.conf may be modified here to use shared resources like sstate-cache and downloads directory with other build environments
                - the build environments used will be removed in the tearDownClass() or tearDownModule() methods
                                * this ensures no residue is left over that we are not aware of
                - we will add a new class oeqa.oeSelfTest that contains the following base methods:

1) A few methods to manipulate variables in poky in a standardized way:
                - oeSelfTest.var_rewrite(filepath_relative_to_poky_location, variable_name, new_variable_value)
                                * resets a variable to the specified value(may be similar to how HOB does to local.conf and bblayers.conf)
                - oeSelfTest.var_append(filepath_relative_to_poky_location, variable_name, appended_variable_value)
                                * appends data to a variable
                - oeSelfTest.var_remove(filepath_relative_to_poky_location, variable_name, remove_variable_value)
                                * removes data from a variable

2) We need to be able to execute tasks in a multiple build directories environment.
                - oeSelfTest.execute(command, build_dir)
                                * this method executes the command 'command' from 'build_dir'
                                * for each execution, the environment is sourced (similar to autobuilder)
                                (if the build directory does not exist, the command will fail. This needs to be taken care of in the setUpClass() method)
                                * it returns the exit code and the output of the command

Additional information/notes:
- class and method naming and structure is not final and open for suggestions
- poky under git is required for the script to work; we will use git to reset modified files to default.
- a policy needs to be set in place(after experience has been gained from using the tool) for working with a shared sstate-cache directory and multiple build environments at a time.
- coding style is very important in order to get a reasonable execution time. At the moment this is not a priority though.
- no strategy has been put in place yet in order to deal with multiple poky environments



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131018/3d90e003/attachment.html>