Model.find raise error in test env

[icotanchev]

In our project, we have a simple table using DynamoDB. We are using the find method to find the record and It works fine in production and development ENVs but in test env, it raises a strange error about undefined method to_sym' for nil:NilClassingems/dynamoid-3.6.0/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb:567:in key_stanza'. In the spec_helper we have Aws.config[:dynamodb] = { stub_responses: true } to stub the responses.

[andrykonchin]

Could you please provide an example of test to reproduce the issue?

[andrykonchin]

I've reproduced the issue and I wouldn't consider it as a bug in Dynamoid.

Dynamoid relies on a table schema declared in a model class (range and hash keys at least). But there are some places when Dynamoid loads actual table meta information with DescribeTable api call (documentation).

As far as I understand stubbing client responses with Aws.config[:dynamodb] = { stub_responses: true } approach actually stubs all the communication with DynamoDB. AWS SDK returns some dummy data with correct structure. And DescribeTable is stubbed as well. But Dynamoid expects that a response object contains table schema - hash and range attribute names. So missing table schema in stubbed response leads to the reported exception.

Example of the stubbed response for the DescribeTable api call which AWS SDK returns in "stub_responses" mode:

A real table schema looks like this one:

As you can see stubbed response contains empty key schema - key_schema=[].

So what options I could suggest.

1. It's possible not to load table definitions at all and to rely completely on a schema declared in a model class. But generally speaking I think it's too strict constraint and would prefer other options. I can imagine cases and features when loading actual table description will be very useful.
2. As a workaround if in tests DynamoDB is completely stubbed - DescribeTable api call may be also stubbed either with mock library (e.g. rspec-mock) or with already mentioned Aws.config[:dynamodb] = { stub_responses: true } approach.

DescribeTable call can be stubbed this way:

Aws.config[:dynamodb] = {
  stub_responses: {
    describe_table: {
      table: { :key_schema=>[{ attribute_name: 'id', key_type: 'HASH' }] }
    }
  }
}

By default Dynamoid uses id attribute as a hash key so it's a working solution unless there is a table which uses not default hash key name.

I checked this approach - find works well and return a dummy model.

[icotanchev]

Hi @andrykonchin. Thanks for fist replay and provided solution, it works for us :)