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 :)

  • There might not be a path from your UI, but if /register/C is an URL that the user could enter in their address bar, then yes you should test for that.
    – Bergi
    Dec 20, 2020 at 16:54
  • Couldn't you get the same error response that you would get from the backend for /register/C also for /register/A//B if those areas become invalid? This doesn't actually sound impossible. Just mock your backend to do that, without adding an unreachable selection for C. Treat it as "handling normal error responses".
    – Bergi
    Dec 20, 2020 at 16:58

2 Answers 2


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.

  • 1
    I agree, I realized my question basically was 'should I harden frontend code against manipulation' but since once delivered it is not under my control I should only test the frontend things I expect to happen, not everything else. The rest is hardening the backend.
    – Samuel
    Dec 20, 2020 at 9:01
  • Error handeling is a legitimate feature, and lack of error handeling is a bug. Let's say they want to disable option B for 3 days. They update their code, and some customer hasn't refreshed his web page, well I'd rather make sure the user has a controlled feedback Dec 27, 2020 at 8:16
  • @Pierre-AntoineGuillaume, Your scenario implies a test for "backend sends response that selection is invalid", which is a test that should exist IMO. That is a different scenario than what the OP was asking about, which was closer to preventing sending B when the browser is refreshed and B no longer existed in the list of selectable items. Dec 27, 2020 at 9:50
  • (IMO) This scenario is a different one, but is is corrolary to "everything works fine". "My info is not up to date anymore" or "the server does not respond" is a pretty valid concern in async consideration, even when everything works fine. It doesn't require anything great either, but it is logic, thus it is breakable. I disagree when you day "you don't have to test what the behavior is if the validation/restriction fails", because most of the bugs I see were produced when legitimate cause of failure were not anticipated, Not only error handeling is a feature, but it adds real value. Dec 27, 2020 at 10:08

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.