go/bindings: update code to pass structs versions tests

go/bindings: update code to pass structs versions tests

Now we should verify struct data header
if we know the version.

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/2b73f4b16c93ea97b4604c2f6e31488e05d853c0

[rogulenko, 2015-02-25 01:58:42]

rogulenko@google.com changed reviewers:
+ jamesr@google.com

[jamesr, 2015-02-25 03:17:57]

jamesr@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2015-02-25 03:17:57]

https://codereview.chromium.org/948343008/diff/20001/mojo/go/tests/validation...
File mojo/go/tests/validation_test.go (right):

https://codereview.chromium.org/948343008/diff/20001/mojo/go/tests/validation...
mojo/go/tests/validation_test.go:299: return nil
why nil?

[rogulenko, 2015-02-25 03:50:56]

https://codereview.chromium.org/948343008/diff/20001/mojo/go/tests/validation...
File mojo/go/tests/validation_test.go (right):

https://codereview.chromium.org/948343008/diff/20001/mojo/go/tests/validation...
mojo/go/tests/validation_test.go:299: return nil
On 2015/02/25 03:17:57, jamesr wrote:
> why nil?

To identify the test for which I want to verify decoded values I check
that the test ends with "_good.data". There is no such test for
Method11. So for Method11 the test check that the code returns errors
correctly.

[jamesr, 2015-02-27 00:54:24]

In my checkout I have:

conformance_mthd11_good_version0.data
conformance_mthd11_good_version0.expected
conformance_mthd11_good_version1.data
conformance_mthd11_good_version1.expected
conformance_mthd11_good_version2.data
conformance_mthd11_good_version2.expected
conformance_mthd11_good_version3.data
conformance_mthd11_good_version3.expected
conformance_mthd11_good_version_newer_than_known_1.data
conformance_mthd11_good_version_newer_than_known_1.expected
conformance_mthd11_good_version_newer_than_known_2.data
conformance_mthd11_good_version_newer_than_known_2.expected
conformance_mthd11_num_bytes_version_mismatch_1.data
conformance_mthd11_num_bytes_version_mismatch_1.expected
conformance_mthd11_num_bytes_version_mismatch_2.data
conformance_mthd11_num_bytes_version_mismatch_2.expected

aren't the _good* ones supposed to pass?

Also the validation tests are supposed to verify that the expected validation
error is produced for a particular piece of bad input, so we should still run on
the bad versions and check the error message.

[rogulenko, 2015-02-27 01:41:06]

On 2015/02/27 00:54:24, jamesr wrote:
> In my checkout I have:
> 
> conformance_mthd11_good_version0.data
> conformance_mthd11_good_version0.expected
> conformance_mthd11_good_version1.data
> conformance_mthd11_good_version1.expected
> conformance_mthd11_good_version2.data
> conformance_mthd11_good_version2.expected
> conformance_mthd11_good_version3.data
> conformance_mthd11_good_version3.expected
> conformance_mthd11_good_version_newer_than_known_1.data
> conformance_mthd11_good_version_newer_than_known_1.expected
> conformance_mthd11_good_version_newer_than_known_2.data
> conformance_mthd11_good_version_newer_than_known_2.expected
> conformance_mthd11_num_bytes_version_mismatch_1.data
> conformance_mthd11_num_bytes_version_mismatch_1.expected
> conformance_mthd11_num_bytes_version_mismatch_2.data
> conformance_mthd11_num_bytes_version_mismatch_2.expected
> 
> aren't the _good* ones supposed to pass?
> 
> Also the validation tests are supposed to verify that the expected validation
> error is produced for a particular piece of bad input, so we should still run
on
> the bad versions and check the error message.

C++ and JS do error code checking, but dart, java and python not:
dart:
https://github.com/domokit/mojo/blob/master/mojo/dart/test/validation_test.da...
java:
https://github.com/domokit/mojo/blob/master/mojo/android/javatests/src/org/ch...
python:
https://github.com/domokit/mojo/blob/master/mojo/python/tests/validation_unit...

[jamesr, 2015-03-03 23:13:42]

This lgtm

The error code issue is separate but please file bugs for it for Go and the
other languages.  Whether the bindings layer uses the validation error code is a
separate issue from whether the validation layer produces the right errors.  The
validation logic is at a lower layer than the bindings and may be used in many
ways.  For instance someone doing data serialization to disk or network will
want to use the validation code but probably not our bindings.  For these cases,
it's important that the validation errors match the specification for
validation.  We check this by having the validation error type checked by the
validation tests.

[rogulenko, 2015-03-04 04:44:49]

Committed patchset #3 (id:40001) manually as
2b73f4b16c93ea97b4604c2f6e31488e05d853c0 (presubmit successful).