Expected outcome effects dictionary

[jmafoster1]

When we set up a driver for the JSON front end, we have something like the following:

        expected_outcome_effects = {
            "Positive": Positive(),
            "Negative": Negative(),
            "NoEffect": NoEffect(),
            "SomeEffect": SomeEffect()
            }

This works great for this kind of effects, but when I want to test for exact values, I have:

        expected_outcome_effects = {
            "Positive": Positive(),
            "Negative": Negative(),
            "NoEffect": NoEffect(),
            "SomeEffect": SomeEffect(),
            "1.0": ExactValue(1.0),
            "0.8": ExactValue(0.8),
            "0.7": ExactValue(0.7),
            "0.65": ExactValue(0.65),
            "0.6": ExactValue(0.6),
            "0.5": ExactValue(0.5),
            "-0.01": ExactValue(-0.01),
        }

This is expanding as I need to add more literal values. Could we perhaps use a function instead, so I could have something like

def expanded_outcome_effects(effect):
  if effect == "Positive":
    return Positive()
  elif effect == "Negative":
    return Negative():
  else:
    return ExactValue(float(effect))

or would that be bad?

[christopher-wild]

Sorry for only just looking at this, going through all the old issues now.

I definitely agree that having to specify each ExactValue isn't ideal. The main downside of the function approach above is that any numeric effect will be assumed to be an ExactValue. Are there ever situations where you may have another numeric based effect?

If not we can refactor to this approach, it would be a breaking change for the frontend though

[jmafoster1]

I'm not sure. At the moment, I think the only supported numerics are exact values. The other possibility, which I've just thought of, is to specify, in the tests.json file, the name of the effect class (Positive, Negative, etc.) and have an additional field for the arguments with which to initialise the class. I think that would be better, and might not necessarily need to be a breaking change.

[jmafoster1]

@f-allian I'm just having a look through the old issues now and saw this one. Is this something that the new frontend could handle?

[jmafoster1]

This relates to #329. Using entrypoints for this would solve this issue.