When testing your JavaScript you need to test more than just that when expected and acceptable values are entered into the script that the script produces the correct result. While testing this particular set of data will confirm that the script functions correctly and does what it is supposed to do it does absolutely nothing with regard to testing what will happen if the data fed into the script is incorrect.
You may have heard of the saying "Garbage In - Garbage Out".
What we need to ensure with our testing of the script is that if "garbage" is fed into the script that the script deals with it appropriately.
As well as the expected and acceptable values that our script is intended to handle in order to do what the script is there to do we also have two additional types of data we need to test.
Expected but unacceptable values are those that the visitor to our site is able to generate as input to our script. This data is expected because visitors can input these values even though the script is not expected to be able to do its normal processing when such values are entered. It is absolutely essential that you test this type of input into your script in order to ensure that the script treats this data appropriately. In many cases the appropriate treatment is to produce an error message telling your visitor what is wrong with their input so that they can correct it.
Of course with some scripts it may not even be obvious what these expected but unacceptable values are until you run a series of tests using a range of values and suddenly discover that there are values which do not produce the expected results. Then you need to modify both your expected test results and the code in order to avoid the unexpected results that you got from the first test.
The other group of values you need to consider testing are those that are both unexpected and unacceptable.These are values that should never occur in the script because there is no way that your visitor should be able to cause the script to try to process those values - unless something goes wrong. Basically this sort of testing is done on sections of your code in order to ensure that the particular section of code can deal with unacceptable input values that should never reach that piece of code if something stuffs up elsewhere that results in such values being passed.
The reason for testing parts of your script in this way is that you are allowing for the possibility of bugs in your script being missed during your testing and limiting the effect that they can have. Since it is impossible to test all of the possible inputs into even a relatively short script you are relying on the results from what you assume are representative samples of data that are expected to cover all of the possibilities that the script is expected to handle.Consider if you manage to miss some value that is going to do something unexpected in the script such as causing a field to overflow that you never expected could ever get anywhere near the maximum value JavaScript supports (and the maximum might vary between browsers with some obscure browser you never even knew existed having a smaller maximum). By testing that sections of your script can deal with values outside the range that they are expected to see you can hopefully resolve at least some of these potential bugs silently within the code itself.
When setting out your test plan and when updating that plan as a result of tests already run you need to consider all three of these groups of tests in order to ensure that your script can both correctly handle the values that you expect it to see and to reduce the chances that bugs will cause the script to do something totally unexpected. While the harm that a JavaScript bug can do is nowhere near as great as the harm that bugs in server side programs can do, it is still far better to try to reduce the effect that undiscovered bugs can have. At the very least it reduces the possibility of visitors getting the wrong opinion of your site because the bug causes the site to crash when they visit.