iestestform : make sure that "don't know" and similar answers are not possible to select with other answers

[kbjarkefur]

Based on feedback from @AurelieRi:

Paraphrased by me:

When a multiple select has options like "don't know", "declined to answer", create a test so that checks that the condition formula is such that you can only select one of them, and that you cannot select them together with any other option.

This is a great suggestion. It will be very difficult to base this test on the label "don"t know", "declined to answer". as this command should work in multiple languages. But we can do this test on the codes "-99", "-88" etc. That once you have negative codes, you this command will have a test that makes sure that any negative code is not combined with any other answer.

While definitely possible, this command needs information from two sheets and we need to come up with a good way to deal with that. This will probably not make the cut for the first version, but we will implement it eventually.

[AurelieRi]

I thought this one would be easier to implement that the index-repeat thing. But probably that is not so easy..
Is ietestform able to link information from the choice sheet and the survey sheet? Could it be possible to have the user indicate what is the code used for don't know and not applicable? If they enter this information in the command iestestform it could be easier. Then we can try to check all constraint column of the multiple select field that allow don't know and/or not applicable to ensure the constraint column contains "count-selected(.)" and "not(selected(${...},'-99')).
Probaly easier to say than to implement. But in general maybe we could cover more tests if the user of the command have the possibility to indicate information about the form, no?

[kbjarkefur]

I like that idea! Cause if we require people to list what codes they use for "don't know" etc. then we can test that those code are used consistently!

On the other hand though, we want to be careful to not require a too specific use case, before we know how users prefer to use this command. Once we release the first version and we have some user feedback I am more inclined to implement something with such specific requirements. And since we opened this thread we will remember to get back to thinking about this once we have user feedback from more users.

Similarly, what makes it too difficult to implement this test is that we want to be careful how we implement the feature that pass information between sheets. It wouldn't be too difficult to do that for this test only, but we do not want to do that, we want something that future tests can also use so we do not have to create a new solution for each tests that require information from multiple sheets. And to do that in a good way we need to know more about these commands.

I think this is a good way to show the difference between coding for a specific thing needed right now in a project, or coding a command that will be used in many different contexts over several years while it is being updated to do more things.

Anyways, I think these are good ideas, and I really appreciate the ideas (so keep them coming), but I hope I have explained why I still want to to wait with implementing them!