Should tests for frontend test for impossible situations?

Question

I am cruising through a situation where I am my own backend and fronend developer. Let's say I have a basic backend API with some call /register/{area}.

The {area} piece is dynamic and can change. Now I have a nice frontend application in angular that provides a selection of various area entries, Let's say they can be "A" and "B".

My backend already has test cases that ensure that the API does not execute /register/C because C would not be valid. So the API guards itself against misuse.

But what's about the frontend? The frontend allows you to pick A or B from a list and executes some javascript code that calls the API above.

The frontend tests verify that you can pick A or B and that the logic executes the proper call to a mocked backend, handles normal responses and error responses, etc.

But a question arose whether I also should test what happens when the user magically selects the invalid value C. Should I write a frontend test for that? Let's say the frontend has a method called registerForArea(area). There is no path from the UI to actually call registerForArea('C') because no normal control flow results in this path.

But in a frontend unit test I of course can verify certain behaviour by manually calling registerForArea('C'), but should I? Remember, the backend call is tested.

I tend not to do it, because testing a path through the frontend that can usually never occur is like testing non public APIs. Sure, never trust the user but facilitating a situation that only misuse would cause opens endless permutations of the question what if the user meddles with parts of the JS which I regard as useless as one has no control over what a user can do in the frontend.

Very interested in other point of views or confirmation of my bias :)

Answer 1

What behavior would you expect to see when a testcase calls registerForArea('C')?

As your area-selection input control is apparently designed such that only valid areas can be selected/entered, I would find it entirely normal if the front-end code blindly passes the selected area on to the backend.

The front-end must make it hard for users to enter invalid data. That can be achieved by validating otherwise unrestricted input or by restricting the input possibilities to only valid inputs.

You should test that the validation and/or input restriction works, but beyond that you don't have to test what the behavior is if the validation/restriction fails.

Answer 2

Your backend should implement the illegal case C probably by reporting an error back. The shipping backend would include that code. If you write tests for the backend, they should test the “impossible” case C because any case should be handled correctly by your backend. If you mock the backend, you should make sure that the mocked backend works the same as the real one, including in case C.

For your front end: The code making the backend call should probably check for the “impossible” case C and not call the backend when it happens, unless your backend explicitly specifies that such a call is legal and how it behaves. That front end would be shipped to a customer. If the front end itself determines which action to take then testing the C case by faking it would be wrong, since the front end used by a customer doesn’t do this.