Maps with optional keys

[whatyouhide]

Today it's quite nasty to generate maps (with fixed keys and generator values) with optional keys. You have to either build on top of fixed_map/1 but it's a bit convolute to add keys optionally and make it shrink towards having no optional keys. I think it might be nice to have a good interface for this. We can't get inspiration from PropEr or QuickCheck because they don't support maps, and test.check only supports hash-map which is our fixed_map/1.

One idea could be to have optional_map/1 that mirrors fixed_map/1 but which shrinks by taking away key-value pairs as well, and then a structured map with optional keys could be built by doing

fixed = %{
  name: string(:alphanumeric),
}
optional = %{
  age: map(integer(), &abs/1),
}

map({fixed, optional}, fn {fixed_map, optional_map} -> Map.merge(fixed_map, optional_map) end)

I am not sure this is a very elegant solution thought. Ideas? \cc @josevalim

[keathley]

The specific problem that I've been experiencing is that its hard to determine issues when there are deeply nested maps with large amounts of keys. I thought initially that the solution might be to have a generator that removes keys from the maps in order to reach the smallest map that could induce a failure. So for instance if we had a map like this:

%{
  foo: 123,
  bar: "abc",
  baz: %{
    some_bad_key: "bad_value"
  }
}

Would shrink to %{baz: %{ some_bad_key: "bad_value" }}.

But often you have to have the other keys for the map to be a valid input. The more I've thought about this the more I've been wondering if the right solution is to change the way that errors are displayed after a test failure. For instance the full generated value could still be output but there could be a secondary section that highlighted or underscored the specific keys that induced the failure.

[whatyouhide]

@keathley the error in the test is test-specific so there's no way for use to know which keys induced the failure (if I understand correctly what you mean).

Deeply nested maps wouldn't be affected by fixed_map/1 or optional_map/1 though: if today you have a fixed_map/1 where a value is a fixed_map/1, the values in the inner map are shrinked first and then the outer map shrinks by shrinking the inner map. With optional keys, it would mean that a map like %{optional1: %{optional2: value}} first shrinks value, then it shrinks by removing optional2, then it shrinks my removing optional1 altogether. I am not sure I see the problem with nested maps 😕

[josevalim]

@whatyouhide if i had to implement this, I would probably use two generators: a fixed map and a generator that renders permutations of a list to drop those values of the map. In pseudo code:

check all map <- map(%{a: x, b: y, c: z, ...}),
          optional_keys <- permutations_of([:d, :m, :s]),
          map = Map.drop(map, optional_keys) do
  ...
end

Do we have anything that generates permutations?

[josevalim]

I am not sure if the permutations thing helps with shrinking though, probably because the shrunk version would be [] that wouldn't remove anything. And a better name than permutations may be subsets.

[whatyouhide]

@josevalim we don't have anything that generates permutations. We can have permutations/1 but for this case sublists/1 may work well as well, and it might be useful in other cases too, not sure.

[whatyouhide]

Ah no, of course if you do permutations/1 you shrink towards having all keys which is not good. I am struggling a bit to find a good API for this because the problem is fairly simple.

[whatyouhide]

@josevalim we can always build optional_map/1 on top of fixed_map/1 and Map.take/2:

def optional_map(map) do
  bind(fixed_map(map), fn gen_map ->
    bind(sublist(Map.keys(gen_map)), fn keys ->
      constant(Map.take(gen_map, keys))
    end)
  end)
end

The problem is that we generate all the values only to throw away at least some of them (if not all of them). However, your solution with Map.drop/2 suffers from the same problem. For this reason I think a "native" optional_map/1 that only generates a sublist of keys and generates a map with only those keys (and the sublist shrinks towards [], meaning empty map) might be a better solution.

[whatyouhide]

Closing this in favor of #41.