What to test for in a simple form where the value of one input field dictates other fields?

Question

Note:- I have added android and iOS tags to this question but it is not necessarily restricted to those platforms.

Consider a simple registration form where the the value of one field dictates what other fields are shown and how they are shown. For example, imagine the following

• You start off by selecting your country from a drop-down/list
• If the native language of that country is not English, you display a text field to enter the language.

Question: What strategy would one adopt to test such a form?

---

To elaborate a bit, of late there has been a push from both the Android and iOS developer communities to move away from MVC (well, on Android that has never existed really) towards other architectures like MVVM or MVP. One major reason cited for this is that sticking to traditional architectures conflates responsibilities of what ought to be several distinct layers. Separating them into derivatives of MVC makes testing easier.

Secondly, both MVVM and MVP have the advantage of isolating the View layer to such an extent that everything right up to view logic can be tested without ever having to touch a real view object. On Android, this means being able to run pure JVM Junit tests to test the view logic.

I suppose my example above falls under the category of view logic. However, it is not clear to me how I can test this without actually instantiating a real View object. Conceptually, I want to verify that if user chooses a country that speaks English natively, then the text field to enter a language is not shown. Otherwise, the text field is shown. How does this translate to non-UI tests?

Answer 1

What strategy would one adopt to test such a form?

You have to separate the GUI from the decision logic by adding a decision function that only depends on business attributes and not on GUI elements:

bool isNativeLanguageInputVisible(RegistrationData currentRegistrationData)

Your GUI would use this decision function to control visibility and your test goes against decision function and not against the GUI.

• curioustechizen: But then, does the decision function "own" the GUI? In other words, control flow goes like this: 1) When user selects a country from drop-down, GUI "calls" decision layer. 2) Decision layer does its business logic and now it has to communicate back to GUI layer. The question that arises is who holds a direct reference to the other layer? Which layer owns the other? Or should it be bi-directional?
• k3b: why do you think that the decision has to call back to the gui? Either the gui or the controller does the job: comboboxNativeLanguage.setVisible(decision.isNativeLanguageInputVisible(currentRegistrationData))
• curioustechizen: I see what you mean. You are saying that the all events are handled in the GUI, and on each event, various properties of the GUI (visibility of dependent fields etc) are updated. However, the values for these properties are decided by the decision layer. Is this understanding correct? I am trying to expand this line of reasoning from this simple example to the more complex real-world form that I am dealing with.
• k3b: that is correct.
• curioustechizen: I'm putting together some code to try this suggestion. Currently tilting in favor of making the calls from Controller because that way the trigger does not need to be a click on the GUI (for example, pre-populating the country value from some saved data somewhere would still invoke the decision layer). Will revert back when I have something interesting to report.