Value mismatch error when values seem to be the 'same'

[casahome2000]

Command

$ tavern-ci --debug some_file.tavern.yaml

Response in Terminal

Value mismatch: '159295' vs '159295'
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/tavern/response.py", line 210, in _validate_block
    assert actual_val == expected_val
AssertionError

Test to save user_id from response

  - name: login
    request:
      url: some_test_url.com/login
      json:
        username: someUser
        password: somePassword
        grant_type: password
      method: POST
      headers:
        content-type: application/json
        accept: application/json
    response:
      status_code: 200
      body:
        token_type: bearer
        scope: user
        expires_in: 604800
      headers:
        content-type: application/json; charset=utf-8
      save:
        body:
          access_token: access_token
          refresh_token: refresh_token
          user_id: user_id

Test to use user_id in subsequent test

  - name: create_book
    request:
      url: some_test_url.com/books
      json:
        title: Some title of a book
      method: POST
      headers:
        content-type: application/json
        accept: application/json
        Authorization: "Bearer {access_token:s}" #working to reuse variable saved
    response:
      status_code: 201
      body:
        user_id: "{user_id}"
      headers:
        content-type: application/json; charset=utf-8

[michaelboulton]

I'm guessing this is because it's an integer and user_id is being implicitly converted to an int at some point.

Because it might be desirable to actually have the distinction between an integer and a string being returned I'm not sure what the best thing to do is to fix this - it should at least print something more useful like

Value mismatch: '159295' (type: int) vs '159295' (type: str)

[benhowes]

@michaelboulton This has been released right?

[Birne94]

Currently, values from variables can only be passed by using string formatting (user_id: "{user_id}"). This loses any information about the original data type.

We should come up with another way of passing variables as they are. This might also be useful for passing whole json-blocks as data. String-formatting should stay as it has its own use case (e.g. Authorization header formatting).

Maybe a special token might be appropriate here. I am not sure which tokens are reserved in the yaml spec, so the symbol might need to be changed.

user_id: $user_id

[michaelboulton]

This can be done using the yaml 'tags' (specs here http://www.yaml.org/spec/1.2/spec.html#id2803311) - for example:

request:
  json:
    user_id: !!int "{user_id_as_int:d}"

and custom tags can also be added (this is used for !include and !uuid).

It should be possible to make this 'pluggable' in future because it is just registering a function (eg

tavern/tavern/util/loader.py

Lines 29 to 30 in 3f395e0

	cls.add_constructor('!include', cls.construct_include)
	cls.add_constructor('!uuid', makeuuid)

)

[Birne94]

Using the default yaml tags does not work, unfortunately, because they are constructed before any string formatting is done.

I propose a solution involving an intermediate token which gets converted after string formatting is done. See #50 for my approach.