@@ -14,8 +14,9 @@ out to us in a GitHub issue, or stop by
14
14
- [ Building] ( #building )
15
15
- [ Testing] ( #testing )
16
16
- [ Overview] ( #overview )
17
- - [ Running All Tests] ( #running-all-tests )
18
- - [ Running a Single Test] ( #running-a-single-test )
17
+ - [ Testing Bindings Generation] ( #testing-bindings-generation )
18
+ - [ Testing Generated Bindings] ( #testing-generated-bindings )
19
+ - [ Testing a Single Header's Bindings Generation and Compiling its Bindings] ( #testing-a-single-headers-bindings-generation-and-compiling-its-bindings )
19
20
- [ Authoring New Tests] ( #authoring-new-tests )
20
21
- [ Test Expectations and ` libclang ` Versions] ( #test-expectations-and-libclang-versions )
21
22
- [ Automatic code formatting] ( #automatic-code-formatting )
@@ -85,38 +86,49 @@ $ cargo build --features testing_only_docs
85
86
86
87
## Testing
87
88
88
- Code for binding generation and testing thereof is in the ` bindgen ` crate.
89
- The following sections assume you are working in that subdirectory.
90
-
91
89
### Overview
92
90
93
91
Input C/C++ test headers reside in the ` tests/headers ` directory. Expected
94
- output Rust bindings live in ` tests/expectations/tests ` .
92
+ output Rust bindings live in ` tests/expectations/tests ` . For example,
93
+ ` tests/headers/my_header.h ` 's expected generated Rust bindings would be
94
+ ` tests/expectations/tests/my_header.rs ` .
95
95
96
- For example, ` tests/headers/my_header.h ` 's expected generated Rust bindings
97
- would be ` tests/expectations/tests/my_header.rs ` .
96
+ There is also the ` ./bindgen-integration ` crate, which uses ` bindgen ` to
97
+ generate bindings to some C++ code, and then uses the bindings, asserting that
98
+ values are what we expect them to be both on the Rust and C++ side.
98
99
99
- Run ` cargo test ` to compare generated Rust bindings to the expectations.
100
+ ### Testing Bindings Generation
100
101
101
- ### Running All Tests
102
+ To regenerate bindings from the corpus of test headers in ` tests/headers ` and
103
+ compare them against the expected bindings in ` tests/expectations/tests ` , run:
102
104
103
105
```
104
- $ cargo test --features testing_only_libclang_$VERSION
106
+ $ cargo test
105
107
```
106
108
107
- Where ` $VERSION ` is one of:
109
+ As long as you aren't making any changes to ` bindgen ` 's output, running this
110
+ should be sufficient to test your local modifications.
108
111
109
- * ` 4 `
110
- * ` 3_9 `
111
- * ` 3_8 `
112
+ ### Testing Generated Bindings
112
113
113
- depending on which version of ` libclang ` you have installed.
114
+ If your local changes are introducing expected modifications in the
115
+ ` tests/expectations/tests/* ` bindings files, then you should test that the
116
+ generated bindings files still compile, and that their struct layout tests still
117
+ pass.
114
118
115
- ### Running a Single Test
119
+ You can do this with these commands:
116
120
117
- To generate bindings for a single test header, compile the bindings, and run the
118
- layout assertion tests for those bindings, use the ` tests/test-one.sh `
119
- script. It supports fuzzy searching for test headers. For example, to test
121
+ ```
122
+ $ cd tests/expectations
123
+ $ cargo test
124
+ ```
125
+
126
+ ### Testing a Single Header's Bindings Generation and Compiling its Bindings
127
+
128
+ Sometimes its useful to work with one test header from start (generating
129
+ bindings for it) to finish (compiling the bindings and running their layout
130
+ tests). This can be done with the ` tests/test-one.sh ` script. It supports fuzzy
131
+ searching for test headers. For example, to test
120
132
` tests/headers/what_is_going_on.hpp ` , execute this command:
121
133
122
134
```
@@ -132,14 +144,17 @@ bindings. Put those in `tests/expectations/tests`.
132
144
If your new test requires certain flags to be passed to ` bindgen ` , you can
133
145
specify them at the top of the test header, with a comment like this:
134
146
147
+ ` new_test_header.hpp ` :
148
+
135
149
``` c
136
150
// bindgen-flags: --enable-cxx-namespaces -- -std=c++14
137
151
```
138
152
139
- Then verify the new Rust bindings compile and pass some basic tests:
153
+ Then verify the new Rust bindings compile and pass their layout tests:
140
154
141
155
```
142
- $ cargo test -p tests_expectations
156
+ $ cd tests/expectations
157
+ $ cargo test new_test_header
143
158
```
144
159
145
160
### Test Expectations and ` libclang ` Versions
@@ -161,6 +176,22 @@ request, and then when Travis CI fails, it will log a diff of the
161
176
expectations. Use the diff to patch the appropriate expectation file locally and
162
177
then update your pull request.
163
178
179
+ Usually, ` bindgen ` 's test runner can infer which version of ` libclang ` you
180
+ have. If for some reason it can't, you can force a specific ` libclang ` version
181
+ to check the bindings against with a cargo feature:
182
+
183
+ ```
184
+ $ cargo test --features testing_only_libclang_$VERSION
185
+ ```
186
+
187
+ Where ` $VERSION ` is one of:
188
+
189
+ * ` 4 `
190
+ * ` 3_9 `
191
+ * ` 3_8 `
192
+
193
+ depending on which version of ` libclang ` you have installed.
194
+
164
195
## Automatic code formatting
165
196
166
197
We use [ ` rustfmt ` ] ( https://github.com/rust-lang-nursery/rustfmt ) to enforce a
0 commit comments