Replacing #to_graphql in tests

[slimdave]

We're currently on 1.13.10 and preparing for the big 2+ upgrade.

In our tests, we habitually send to_graphql to a Types::BaseInputObject class before calling new on it, although my recollection of why we do that is foggy. 😬

(Was it required in order to instantiate the Singleton? Certainly Types::Search::WorkSearchAttributes doesn't seem to respond to new until we do)

  context "with searches" do
    let(:work_search) do
      Types::Search::WorkSearchAttributes.to_graphql

      Types::Search::WorkSearchAttributes.new(
        {
          subtitleCont:    "subtitle contents",
          subtitleEq:      "subtitle is equal to",
          subtitlePresent: true,
          titleCont:       "title contents",
          titleEq:         "title is equal to",
          idEq:            876,
          after:           543
        },
        context:       OpenStruct.new(current_client: client),
        defaults_used: Set.new
      )
    end

I'm wondering what the approved method would be for achieving this aim? Or are we doing things completely wrong here?

[rmosolgo]

why we do that

Yep, this isn't the first time I've heard of it! (Even the graphql-ruby tests did it.) In short, when a legacy Input Object definition was created, it also created a custom GraphQL::Query::Arguments subclass which contained some behavior pertaining to the input object's specific arguments.

Inside InputObject#initialize, it would do different kinds of initialization given different inputs. Legacy-style inputs would still work if the custom Arguments subclass was also present. So probably, when migrating from .define-based definitions to class-based definitions, adding .to_graphql (which, under the hood, prepared that specialized Arguments subclass) made the previous initialization code still work.

Here are couple examples from the graphql-ruby tests for how to migrate this code:

graphql-ruby/spec/graphql/schema/input_object_spec.rb

Lines 627 to 638 in 2b35a5d

	arg_values = {
	a: 1,
	b: 2,
	inputObject: InputObjectDigTest::TestInput1.new(nil, ruby_kwargs: { d: 3, e: 4 }, context: nil, defaults_used: Set.new)
	}
	input_object = InputObjectDigTest::TestInput2.new(
	nil,
	ruby_kwargs: arg_values,
	context: nil,
	defaults_used: Set.new
	)

In short, pass nil as the first positional argument (this is used for legacy arguments), then pass the hash of arguments as ruby_kwargs: ... instead. If it doesn't work out of the box, try substituting camel-cased keys for underscore-cased keys (for example, subtitleEq => subtitle_eq). If it still doesn't work, please share the error or behavior you encounter when you try it!

[slimdave]

Oh, that has very nearly got me there!

Where we have:

module Types
  module Search
    class ProductSearchAttributes < Types::BaseInputObject
      description "Attributes for searching for products"

      argument  :after,
                Integer,
                description: "Where the product's internal ID is greater than the value",
                required:    false,
                as:          :id_gt

... I was testing with ...

      Types::Search::ProductSearchAttributes.to_graphql

      Types::Search::ProductSearchAttributes.new(
        {
          after:                   987_654,

... but when supplying ruby_kwargs it looks as if the test on an argument with as: needs to reference (in this example) id_gt rather then the argument after?

So

      Types::Search::ProductSearchAttributes.new(
        nil,
        ruby_kwargs:
          {
            id_gt:                   987_654,

... (and hence needing to use underscore-case rather than camel-case)?

[rmosolgo]

Yeah, I'd believe it! IIRC as: ... is applied when turning GraphQL inputs into Ruby keyword arguments. So that'd make sense you'd have to substitute those keys for plain ruby initialization, too.

[slimdave]

Makes sense, thanks Robert.