-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ClientHelper / SpecHelper improvement with source generation tests #267
Conversation
|
||
module ClientHelper | ||
class << self | ||
def sample_shapes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this model should work the same way our other smithy models do - we should have a model.smithy + model.json and we load that here.
Its terrible to work in smithy json. Its even worse to work in ruby hashes that are trying to look like json.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The advantage to having the model json in code, prior to generation, is that we can modify contents in the test. For example v3 code has tests like:
shapes['StructureShape']['members']['String']['locationName'] = 'str'
expect(json(string: 'abc')).to eq('{"str":"abc"}')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I like that ability - I guess I'm not suggesting that we can't have that - just that where the default comes from is a smithy model rather than an in code hash which is just kinda ugly and super annoying to edit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally this is only written once, but yeah we can have a fixture default I suppose, but we need a way to modify it at runtime I think.
expect(defined?(Weather::Types::WeldShouldNotExist)).to be nil | ||
expect(defined?(Weather::Types::OtherWeldShouldNotExist)).to be nil | ||
context 'source code' do | ||
include_context 'generated client from source', { fixture: 'weather' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still struggle with this naming. What about "generated in-memory client"
gems/smithy/spec/spec_helper.rb
Outdated
raise e | ||
end | ||
|
||
def generate_client_from_source(options = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from source I still find confusing maybe generate_in_memory_client
or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice - looks good - I think nicely cleans up our specs!
Refactor spec helper to understand how to generate clients, types, servers, and use a client helper which uses dynamic or static code generation. Also adds source code tests to component tests.