| | 331 | == Test failures == |
| | 332 | |
| | 333 | Firstly check the status of the build at for example i:build/dybinst, look for |
| | 334 | * consistency between slaves |
| | 335 | * changes in the numbers of tests |
| | 336 | |
| | 337 | Inconsistency between slaves indicates either : |
| | 338 | * architecture dependence (unlikely for failures at test stage, not uncommon for compilation issues) |
| | 339 | * difference between the working copies of the slave : perhaps due to a forgotten commit resulting in a conflict when someone else makes changes |
| | 340 | |
| | 341 | Unexpected changes in the number of tests, usually indicate failure to import a python module |
| | 342 | |
| | 343 | |
| | 344 | === Switching off a test === |
| | 345 | |
| | 346 | You can switch off a failing test by defining a {{{__test__}}} attribute of the test function to be {{{False}}}, eg: |
| | 347 | {{{ |
| | 348 | #!py |
| | 349 | def test_example(): |
| | 350 | assert 0 |
| | 351 | |
| | 352 | test_example.__test__ = False |
| | 353 | }}} |
| | 354 | |
| | 355 | |
| | 356 | |
| | 357 | |
