| 1 | [[TracNav(NuwaNav)]] |
| 2 | = Testing Quickstart = |
| 3 | |
| 4 | == Overview == |
| 5 | |
| 6 | The automated testing system uses the '''Bitten''' extension to Trac which provides a '''slave''' and '''master''' system : |
| 7 | || slave || any machine capable of running !NuWa, with '''nosebit''' installed || |
| 8 | || master || dybsvn Trac instance http://dayabay.ihep.ac.cn/tracs/dybsvn || |
| 9 | |
| 10 | = '''nosebit''' = |
| 11 | |
| 12 | '''nosebit''' denotes a collection of packages : |
| 13 | |
| 14 | || [http://www.somethingaboutorange.com/mrl/projects/nose/ nose] || test discovery/running, orchestration with coverage and profilers || |
| 15 | || [http://peak.telecommunity.com/DevCenter/setuptools setuptools] || needed to install nose plugins, also provides [http://peak.telecommunity.com/DevCenter/EasyInstall easy_install] tool || |
| 16 | || xmlnose || nose plugin to provide test results in the xml format needed by the bitten master || |
| 17 | || bitten-slave from [http://bitten.edgewall.org/ bitten] || automated build/test runner, pure python || |
| 18 | |
| 19 | == Installation of '''nosebit''' into Nuwa python == |
| 20 | |
| 21 | If '''which nosetests''' draws a blank when you are in your CMT environment then you(or your administrator) will |
| 22 | need to rerun [db:Offline_Software_Installation dybinst] with commands like : |
| 23 | {{{ |
| 24 | ./dybinst trunk checkout |
| 25 | ./dybinst trunk external nosebit |
| 26 | }}} |
| 27 | to get uptodate and install the currently non-default '''nosebit''' external. Which provides the tools : |
| 28 | || nosetests || test running entry point || |
| 29 | || easy_install || install python packages into NuWa python || |
| 30 | || bitten-slave || communicates with bitten-master for instructions on tests (or builds) to be performed || |
| 31 | |
| 32 | Check your installation by getting into the CMT controlled environment of your default package, and trying these |
| 33 | tools: |
| 34 | {{{ |
| 35 | dyb__ ## see below for details |
| 36 | which nosetests ## also check easy_install and bitten-slave |
| 37 | }}} |
| 38 | |
| 39 | The path returned should be beneath the '''external/Python''' directory of your !NuWa installation. |
| 40 | Verify that the list of plugins includes '''xml-output''' (used by automated testing system) : |
| 41 | {{{ |
| 42 | nosetests --plugins | grep xml-output |
| 43 | Plugin xml-output |
| 44 | }}} |
| 45 | |
| 46 | = Utility dyb!__* functions = |
| 47 | |
| 48 | These utility functions are used by the automated build and test system, so to investigate failures |
| 49 | it is best to use these functions first to reproduce the failures, then proceed with using |
| 50 | '''nosetests''' directly as you zero in on the failing tests. |
| 51 | |
| 52 | Define the dyb!__* functions in your environment with something like |
| 53 | the below called from your $HOME/.bash_profile |
| 54 | {{{ |
| 55 | . $NUWA_HOME/dybgaudi/DybTest/scripts/dyb__.sh |
| 56 | }}} |
| 57 | |
| 58 | Use tab-completion in your bash shell to see the functions available : |
| 59 | {{{ |
| 60 | dyb__<tab> |
| 61 | }}} |
| 62 | |
| 63 | Check your bash , if nothing is returned by the below function then your bash does not need the workaround of setting environment variable NUWA_HOME |
| 64 | {{{ |
| 65 | dyb__old_bash |
| 66 | }}} |
| 67 | |
| 68 | Customize the defaults by overriding the '''dyb!__buildpath''' function to feature your favourite repository path, for example by putting the |
| 69 | below into your $HOME/.bash_profile. See the below section on bash functions if they are new to you. |
| 70 | {{{ |
| 71 | dyb__buildpath(){ echo ${BUILD_PATH:-dybgaudi/trunk/Simulation/GenTools} ; } |
| 72 | }}} |
| 73 | OR : |
| 74 | {{{ |
| 75 | dyb__buildpath(){ echo ${BUILD_PATH:-dybgaudi/trunk/DybRelease} ; } |
| 76 | }}} |
| 77 | |
| 78 | * use BUILD_PATH if defined, otherwise the default path provided |
| 79 | * CAUTION: you must provide a repository path (with the '''trunk''' ) not a working copy path |
| 80 | |
| 81 | == dyb!__usage == |
| 82 | |
| 83 | The '''dyb!__usage''' function provides brief help on the most important functions : |
| 84 | {{{ |
| 85 | dyb__usage |
| 86 | |
| 87 | Top level functions provided : |
| 88 | |
| 89 | dyb__ [siteroot-relative-path] |
| 90 | path defaults to dybgaudi/Simulation/GenTools |
| 91 | jump into CMT controlled environment |
| 92 | and wc directory of a siteroot relative path, |
| 93 | the relative path must either end with "cmt" or with |
| 94 | a directory that contains the "cmt" directory |
| 95 | |
| 96 | eg |
| 97 | dyb__ lcgcmt/LCG_Interfaces/ROOT/cmt |
| 98 | dyb__ lcgcmt/LCG_Interfaces/ROOT |
| 99 | dyb__ dybgaudi/DybRelease |
| 100 | |
| 101 | dyb__update |
| 102 | uses dybinst to svn update and rebuild |
| 103 | dyb__checkout : ./dybinst trunk checkout |
| 104 | dyb__rebuild : ./dybinst -c trunk projects |
| 105 | |
| 106 | dyb__test [options-passed-to-nosetests] |
| 107 | |
| 108 | uses dyb__context to setup the environment and directory |
| 109 | then invokes nosetests with the options passed |
| 110 | |
| 111 | |
| 112 | }}} |
| 113 | |
| 114 | |
| 115 | = Nose test running = |
| 116 | |
| 117 | Get into the CMT managed environment of your default build path and run '''nosetests''' with the function : |
| 118 | {{{ |
| 119 | dyb__test [arguments-are-passed-directly-to-nosetests] |
| 120 | }}} |
| 121 | The automated tests are run from the package directory, that is the parent directory of the cmt directory. |
| 122 | Currently a simple '''nosetests''' invocation is performed, changing this simplest approach to avoid issues with test isolation |
| 123 | may be necessary in future. |
| 124 | |
| 125 | If you are already in the appropriate environment you can run tests with |
| 126 | '''nosetests''' directly. |
| 127 | |
| 128 | == nosetests basic usage == |
| 129 | |
| 130 | Search for tests using the default test finding approach in the current directory, with command : |
| 131 | {{{ |
| 132 | nosetests |
| 133 | }}} |
| 134 | For your tests to be found, |
| 135 | * collect them in the '''tests''' folder of your project folder |
| 136 | * name the python modules test_*.py |
| 137 | * name the test functions test_* |
| 138 | |
| 139 | See the example of the '''gentools''' tests in |
| 140 | * dybsvn:/dybgaudi/trunk/Simulation/GenTools/tests |
| 141 | |
| 142 | You can also run the tests from specific directories or modules with eg |
| 143 | {{{ |
| 144 | nosetests tests/test_look.py |
| 145 | }}} |
| 146 | |
| 147 | == nosetests options == |
| 148 | |
| 149 | Nosetests has a large number of options, see them listed with : |
| 150 | {{{ |
| 151 | nosetests --help |
| 152 | }}} |
| 153 | |
| 154 | Some of the most useful ones are : |
| 155 | || -v / -vv / -vvv || verbosity control, default is very terse just a "." for a successful test || |
| 156 | || -s / --no-capture || stdout/stderr for failing tests is usually captured and output at the end of the test run, use this to output immediately || |
| 157 | |
| 158 | == nose documentation == |
| 159 | |
| 160 | '''nosetests''' is the command line tool that exposes the functionality of the '''nose''' |
| 161 | python package. Access the '''pydoc''' for the '''nose''' package with : |
| 162 | {{{ |
| 163 | pydoc nose |
| 164 | }}} |
| 165 | |
| 166 | Or see it online at |
| 167 | * http://www.somethingaboutorange.com/mrl/projects/nose/ |
| 168 | |
| 169 | |
| 170 | |
| 171 | = Automated Test Running = |
| 172 | |
| 173 | == Bitten recipes == |
| 174 | |
| 175 | The Bitten master manages XML '''recipes''' for automated building and test running. |
| 176 | Recipes are associated with repository paths, to form the '''builds'''. |
| 177 | Following svn checkins within the paths, builds are assigned "pending" status. |
| 178 | |
| 179 | An example of a recipe : |
| 180 | * dybsvn:/dybgaudi/trunk/DybTest/recipes/nosetests.xml |
| 181 | |
| 182 | {{{ |
| 183 | #!xml |
| 184 | |
| 185 | <!DOCTYPE build [ |
| 186 | <!ENTITY slav " export BUILD_PATH=${path} ; export BUILD_CONFIG=${config} ; export BUILD_REVISION=${revision} ; export BUILD_NUMBER=${build} ; " > |
| 187 | <!ENTITY nuwa " export NUWA_HOME=${nuwa.home} ; export NUWA_VERSION=${nuwa.version} ; export NUWA_SCRIPT=${nuwa.script} ; " > |
| 188 | <!ENTITY scpt " pwd ; iwd=$PWD ; . $NUWA_HOME/$NUWA_SCRIPT ; " > |
| 189 | <!ENTITY env " &slav; &nuwa; &scpt; " > |
| 190 | ]> |
| 191 | |
| 192 | |
| 193 | <build |
| 194 | xmlns:python="http://bitten.cmlenz.net/tools/python" |
| 195 | xmlns:svn="http://bitten.cmlenz.net/tools/svn" |
| 196 | xmlns:sh="http://bitten.cmlenz.net/tools/sh" |
| 197 | > |
| 198 | |
| 199 | <!-- |
| 200 | the NUWA_HOME is needed to work with older bash that does not have BASH_SOURCE |
| 201 | --> |
| 202 | |
| 203 | <step id="update" description="dybinst checkout and rebuild " onerror="continue" > |
| 204 | <sh:exec executable="bash" output="hello.out" |
| 205 | args=" -c " &env; dyb__hello ; echo it returned $? " " /> |
| 206 | <sh:exec executable="bash" output="update.out" |
| 207 | args=" -c " &env; dyb__update ; echo it returned $? " " /> |
| 208 | </step> |
| 209 | |
| 210 | <step id="txttest" description="Run tests with txt output " onerror="continue" > |
| 211 | <sh:exec executable="bash" output="txttest.out" |
| 212 | args=" -c " &env; dyb__test " " /> |
| 213 | </step> |
| 214 | |
| 215 | <step id="xmltest" description="Run tests with xml output " onerror="continue" > |
| 216 | <sh:exec executable="bash" output="xmltest.out" |
| 217 | args=" -c " &env; dyb__test --with-xml-output --xml-outfile=$iwd/nosetests.xml " " /> |
| 218 | <python:unittest file="nosetests.xml" /> |
| 219 | </step> |
| 220 | |
| 221 | </build> |
| 222 | |
| 223 | }}} |
| 224 | |
| 225 | A running Bitten slave polls the master (using HTTP) to see if there are any pending builds that it can perform. |
| 226 | If there are it GETs the corresponding recipe and configuration parameters such as the BUILD_PATH from the master and |
| 227 | follows the steps of the recipe reporting progress to the master after each step. |
| 228 | |
| 229 | == Setup/configure a bitten slave == |
| 230 | |
| 231 | Define some functions for configuration/control of the slave |
| 232 | {{{ |
| 233 | . $NUWA_HOME/dybgaudi/DybTest/scripts/bitrun.sh |
| 234 | }}} |
| 235 | |
| 236 | {{{ |
| 237 | bitrun-usage |
| 238 | }}} |
| 239 | |
| 240 | The slave is configured using two files, one for the credentials/url with which to connect to |
| 241 | the master $HOME/.bitrunrc : |
| 242 | {{{ |
| 243 | # |
| 244 | # name used for logfile and tmp directory identification |
| 245 | # |
| 246 | local name=trialrun |
| 247 | |
| 248 | # |
| 249 | # "builds" url of the master trac instance and credentials with which to connect |
| 250 | # |
| 251 | local url=http://dayabay.ihep.ac.cn/tracs/dybsvn/builds |
| 252 | local user=slave |
| 253 | local pass=youknowit |
| 254 | |
| 255 | # |
| 256 | # absolute path to slave config file |
| 257 | # |
| 258 | local cfg=/disk/d3/dayabay/local/dyb/trunk_dbg/NuWa-trunk/dybgaudi/DybTest/recipes/grid1.cfg |
| 259 | |
| 260 | }}} |
| 261 | |
| 262 | And a second defining the characteristics of the !NuWa installation |
| 263 | * dybsvn:/dybgaudi/trunk/DybTest/recipes/grid1.cfg |
| 264 | |
| 265 | {{{ |
| 266 | # |
| 267 | # configuration for a bitten slave |
| 268 | # |
| 269 | # the master deals in repository paths hence have to strip |
| 270 | # the "trunk" to get to working copy paths |
| 271 | # |
| 272 | [nuwa] |
| 273 | home = /disk/d3/dayabay/local/dyb/trunk_dbg/NuWa-trunk |
| 274 | version = trunk |
| 275 | script = dybgaudi/DybTest/scripts/dyb__.sh |
| 276 | }}} |
| 277 | |
| 278 | The quantites defined are accessible within the recipe context as eg: |
| 279 | {{{ |
| 280 | ${nuwa.home} |
| 281 | }}} |
| 282 | |
| 283 | == slave running == |
| 284 | |
| 285 | The slave will poll the master looking for pending builds that can be performed by the slave, based on |
| 286 | match criteria configured in the master. |
| 287 | When a pending build is found that matches the slave, the steps of the build are done and reported back to the master. |
| 288 | Test outcomes in XML are reported to the the master, which parses them and places into the Trac database |
| 289 | ready for presentation. |
| 290 | |
| 291 | To start the slave: |
| 292 | {{{ |
| 293 | bitrun-start [options-passed-to-slave] |
| 294 | }}} |
| 295 | |
| 296 | This function invokes the '''bitten-slave''' command which does the setup of working directories and configuration file access. |
| 297 | Options to the function are passed to the command |
| 298 | |
| 299 | Useful options for initial debugging : |
| 300 | || -s, --single || exit after completing a single build || |
| 301 | || -n, --dry-run || do not report results back to master || |
| 302 | || -i SECONDS, --interval=SECONDS || time to wait between requesting builds, poll interval (default 300 s) || |
| 303 | |
| 304 | |
| 305 | = Bash Functions Primer = |
| 306 | |
| 307 | Define the function : |
| 308 | {{{ |
| 309 | demo-func(){ |
| 310 | echo $FUNCNAME hello [$BASH_SOURCE] |
| 311 | } |
| 312 | }}} |
| 313 | |
| 314 | Invoke it : |
| 315 | {{{ |
| 316 | demo-func |
| 317 | demo-func hello [] |
| 318 | }}} |
| 319 | |
| 320 | Show the definition : |
| 321 | {{{ |
| 322 | type demo-func |
| 323 | demo-func is a function |
| 324 | demo-func () |
| 325 | { |
| 326 | echo $FUNCNAME hello [$BASH_SOURCE] |
| 327 | } |
| 328 | }}} |
| 329 | |
| 330 | |
| 331 | |
| 332 | |
| 333 | |
| 334 | |