I want to write a test that accepts an input object argument as a variable. The input object includes a nested field that is an enum type. I understand that from the client’s perspective, enum types are the unquoted uppercase version (e.g. ENUM_TYPE ) of their lowercase atom equivalents ( :enum_type ) within Absinthe. But in my test I cannot pass the variables map with the nested enum value as an unquoted string, as it is a syntax error, and writing the mutation by hand with no variables is not trivial. Is there an easier way then manually creating a large heredoc-style (triple quoted string) input object that includes the raw ENUM_TYPE?
Have you tried using a string? 
like "THIS"
Yes. Here’s some more clarification of the problem. This is a valid request payload for a mutation that includes an enum type with values START or STOP:
{“query”:“mutation {\n\trunCommand (command: START, controllerId: 148, minutes: 1, zoneIndex: >1)\n}”,“variables”:{“input”:{“controllerId”:“148”,“siteId”:“43”,“date”:“2017-01-01 12:12:12”,“title”:“Inspection >Title”,“inspectionType”:5,“zones”:}}}
Notice how the START is void of quotes. If I quote it using the Graphiql GUI (or in tests) like this:
mutation {
runCommand (command: “START”, controllerId: 148, minutes: 1, zoneIndex: 1)
}
then the result is:
{
“errors”: [
{
“locations”: [
{
“column”: 14,
“line”: 2
}
],
“message”: “Argument \“command\” has invalid value \“START\”.”
}
]
}
In variables, you can just do "START" with quotes.
You are both correct. I got confused for some reason. So yes, I can use a variables map in my tests to include enum argument types like %{some_arg: “MY_ENUM”}
I’m also super happy that I can specify the raw database value of each enum value which is commonly an integer for legacy implementations of an enum type on the database side. Now with something like this I don’t have to map my raw integer type to and from the absinthe-internal atom as I was doing before.
enum :my_enum do
value :enum_a, as: 1
value :enum_b, as: 2
end
1 Like
