Difference between revisions of "Cwscheckapi"
(draft) |
(add content) |
||
| Line 1: | Line 1: | ||
'''D R A F T''' | '''D R A F T''' | ||
| − | To avoid regressions in the UnoAPI | + | To avoid regressions in the UnoAPI '''CwsCheckApi''' must be executed as a step before '''readyForQA'''. |
==Concept of mandatory UnoAPITests for CWS== | ==Concept of mandatory UnoAPITests for CWS== | ||
| Line 17: | Line 17: | ||
If an exception is '''approved''', the developer has to do the following: | If an exception is '''approved''', the developer has to do the following: | ||
*write a new Issue | *write a new Issue | ||
| − | *update ''$MODULE.sce'' and/or ''knownissues.xcl'' | + | *update ''$MODULE.sce'' and/or ''knownissues.xcl'' with the issue information. |
| − | ==== Exception | + | *run the '''cwscheckapi''' script again. The result '''must''' PASSED.OK |
| + | ==== approve an Exception ==== | ||
| + | If you think you need an exception you have to inform your QA representative and your manager. An exception could break in the UnoAPI! But it also possible that the test itself needs an update. | ||
| + | |||
| + | ==CwsCheckApi== | ||
| + | cwscheckapi is an commandline script. You will find it here: | ||
| + | $SRC_ROOT/solenv/bin/cwscheckapi[.btm] | ||
| + | It is similar to [[checkapi]]. | ||
| + | === Office installation === | ||
| + | At first we need an Office to test. Therefore an Office need to be installed. While Windows 2003 Terminal-Server makes trouble to install an Office without user interaction the cwscheckapi goes a different way. It pack (dmake PKGFORMAT=installed) a runnable office. You will mind this not a correct installed office and you are right. The cwscheckapi should not test the installer, it should only test the UnoAPI. The Office will be installed here: | ||
| + | $TMP/$USERNAME/cwscheckapi | ||
| + | === Test the modules === | ||
| + | After a successful packaging the [[runner]], which is the main application here, starts a query to [[EIS]] for all added modules to the CWS. If a module contains | ||
| + | $MODULE/qa/unoapi | ||
| + | all [[UnoAPITest]]s will be executed. | ||
| + | === Test is finished === | ||
| + | At the end of the test run you will get a test result. This should look like this: | ||
| + | ***** State for complex.unoapi.CheckModuleAPI ****** | ||
| + | Whole unit: PASSED.OK | ||
| + | **************************************************** | ||
| + | LOG> ********** end test ************* | ||
| + | LOG> Finished module(auto) | ||
| + | ***** State for complex.unoapi.CheckModuleAPI ****** | ||
| + | Whole unit: PASSED.OK | ||
| + | **************************************************** | ||
| + | Job -o complex.unoapi.CheckModuleAPI::module(auto) done | ||
| + | ==== Test is OK ==== | ||
| + | Your cws get an attachment in [[EIS]] which look like this: | ||
| + | /var/tmp/UnoApiCwsStatuscws_$CWS_unxsoli.PASSED.OK.txt | ||
| + | All is OK :-) | ||
| + | ==== Test is FAILED ==== | ||
[[Category:API]] | [[Category:API]] | ||
[[Category:UnoAPITest]] | [[Category:UnoAPITest]] | ||
Revision as of 20:12, 5 May 2008
D R A F T
To avoid regressions in the UnoAPI CwsCheckApi must be executed as a step before readyForQA.
Contents
Concept of mandatory UnoAPITests for CWS
CWS is ready
If the CWS is ready the developer has to run cwscheckapi. checkcws calls an UnoAPITest for all modules which are added to the cws. If the result is FAILED the developer has
- to fix the failure inside the implementation
- to get an exception
To get the later one the developer must have good arguments why he/she is not able to fix the implementation.
If the UnoAPITest works fine with state state OK the CWS could be set readyForQA
Exception treatment
If an exception is approved, the developer has to do the following:
- write a new Issue
- update $MODULE.sce and/or knownissues.xcl with the issue information.
- run the cwscheckapi script again. The result must PASSED.OK
approve an Exception
If you think you need an exception you have to inform your QA representative and your manager. An exception could break in the UnoAPI! But it also possible that the test itself needs an update.
CwsCheckApi
cwscheckapi is an commandline script. You will find it here:
$SRC_ROOT/solenv/bin/cwscheckapi[.btm]
It is similar to checkapi.
Office installation
At first we need an Office to test. Therefore an Office need to be installed. While Windows 2003 Terminal-Server makes trouble to install an Office without user interaction the cwscheckapi goes a different way. It pack (dmake PKGFORMAT=installed) a runnable office. You will mind this not a correct installed office and you are right. The cwscheckapi should not test the installer, it should only test the UnoAPI. The Office will be installed here:
$TMP/$USERNAME/cwscheckapi
Test the modules
After a successful packaging the runner, which is the main application here, starts a query to EIS for all added modules to the CWS. If a module contains
$MODULE/qa/unoapi
all UnoAPITests will be executed.
Test is finished
At the end of the test run you will get a test result. This should look like this:
***** State for complex.unoapi.CheckModuleAPI ****** Whole unit: PASSED.OK **************************************************** LOG> ********** end test ************* LOG> Finished module(auto) ***** State for complex.unoapi.CheckModuleAPI ****** Whole unit: PASSED.OK **************************************************** Job -o complex.unoapi.CheckModuleAPI::module(auto) done
Test is OK
Your cws get an attachment in EIS which look like this:
/var/tmp/UnoApiCwsStatuscws_$CWS_unxsoli.PASSED.OK.txt
All is OK :-)
