|
| 1 | +BAP Test suite |
| 2 | +============== |
| 3 | + |
| 4 | +This repository contains tests and test artifacts for Binary Analysis |
| 5 | +Platform. We use DejaGNU testing framework to glue everything in one |
| 6 | +piece. The tests are organized around different tools, namely `bap`, |
| 7 | +`mc`, `byteweight` (to be added), and so on. |
| 8 | + |
| 9 | +Usage |
| 10 | +===== |
| 11 | + |
| 12 | +Testing the Platform |
| 13 | +-------------------- |
| 14 | + |
| 15 | +The repository was designed to be ran automatically by Travis CI, but |
| 16 | +still can be used manually. Just clone it, make sure that you have |
| 17 | +`dejagnu` installed on your system, and run: |
| 18 | + |
| 19 | +``` |
| 20 | +make check |
| 21 | +``` |
| 22 | + |
| 23 | +This will run all tests for all tools. To test only specific `$tool`, run |
| 24 | + |
| 25 | +``` |
| 26 | +runtest --tool=$tool |
| 27 | +``` |
| 28 | + |
| 29 | +To run only a specific suite from a `file.exp` of a `$tool` use: |
| 30 | + |
| 31 | +``` |
| 32 | +runtest --tool=$tool file.exp |
| 33 | +``` |
| 34 | + |
| 35 | +See `man runtest` for more information. |
| 36 | + |
| 37 | + |
| 38 | +Adding new test |
| 39 | +--------------- |
| 40 | + |
| 41 | +To add a new test to an existing tool create a file `<testname>.exp` |
| 42 | +in a folder, that contains tests for the tool. For example, to add a |
| 43 | +new test to a `bap` frontend, add it to `bap.tests`. The tests are |
| 44 | +written in Tcl extended with `expect` command. The DejaGNU framework |
| 45 | +adds few functions, such as `pass`, `fail`. Even more functions are |
| 46 | +added by tool specific libraries, the `lib/$tool.exp` is evaluated |
| 47 | +before `$tool` test, making all its definitions available. Also |
| 48 | +`site.exp` file defines site configuration parameters (see Structure |
| 49 | +section below, for information on a structure of the suite). |
| 50 | + |
| 51 | +Adding new tool |
| 52 | +--------------- |
| 53 | + |
| 54 | +To add new tool `$tool`, you need to create: |
| 55 | +- a folder `$tool.tests` where test suites will be stored; |
| 56 | +- add this test to the Makefile `TOOLS` variable |
| 57 | +- add `lib/$tool.exp` as a tool support package |
| 58 | + |
| 59 | + |
| 60 | +Adding new test artifact |
| 61 | +------------------------ |
| 62 | + |
| 63 | +We store artifacts in binary mode and if possible in source |
| 64 | +code. There are few reasons to commit the artifacts in the binary |
| 65 | +form: |
| 66 | + |
| 67 | +1. it is quite to compile them in a portable way |
| 68 | +2. sometimes there're now source code for an artifact |
| 69 | + |
| 70 | +The artifact name should have form `tripple-name`, where `tripple` is |
| 71 | +a canonical target representation, e.g., `arm-linux-gnueabi`, |
| 72 | +`i686-w64-mingw32`, etc. An example of a well-formed fully tripplified |
| 73 | +name would be: `arm-linux-androideabi-echo`. |
| 74 | + |
| 75 | +Once a new test artifact is added, make sure that all existing tests |
| 76 | +are passing. If the don't then either create an issue (if you think, |
| 77 | +that they should pass), or fix the test. |
| 78 | + |
| 79 | +Structure |
| 80 | +========= |
| 81 | + |
| 82 | +The repository structure is defined by requirements of the DejaGNU |
| 83 | +framework. For each `$tool` there is a folder `$tool.tests` that |
| 84 | +contains tests for this `$tool`. A library `lib/$tool.exp` contains |
| 85 | +code that can be reused across different tools. Other modules from |
| 86 | +this folder can be loaded with `load_lib` procedure provide by the |
| 87 | +DejaGNU framework, e.g., `common.exp` is used for sharing code between |
| 88 | +all tools. The `config` folder contains configuration files (i.e., |
| 89 | +files that define configuration constants) specific for |
| 90 | +boards. (Currently we support only unix board, so at this point of |
| 91 | +time it can be ignored). |
| 92 | + |
| 93 | +The `src` folder contains source code for test artifacts. Each |
| 94 | +test-artifact that has a source should be rebuildable from the source, |
| 95 | +using a recipe in `src/Makefile`. The `src/Makefile` can contain |
| 96 | +recipes that are not portable. |
| 97 | + |
| 98 | +The `bin` folder contains the test artifacts built from sources `src`, |
| 99 | +or obtained from some obscure system. The folder must contain only |
| 100 | +binary files for testing. If some object data is needed, then it |
| 101 | +should be stored in corresponding test folder in the test itself or as |
| 102 | +a file with `.dat` extension (or any other suitable extension). If you |
| 103 | +want to add some meta information to a file that is not backed by a |
| 104 | +source code, it would be a good idea to add a textual file with the |
| 105 | +same basename as the file into the `src` folder. |
| 106 | + |
| 107 | + |
| 108 | +Current Status |
| 109 | +============== |
| 110 | + |
| 111 | +Currently the suite is an alpha stage and is not yet integrated with |
| 112 | +Travis CI. It will be as soon, as we will get `0` on the `make check`. |
0 commit comments