Today I ran into a new problem in my Angular application. My Jasmine unit tests were running FOREVER. Every time the tests finished they just kept running again and again. I reached 1505 out of 490 unit tests run. I was very confused! location.reload was the problem!
After finding the exact tests that were the culprit. (Thank you small commits!) It was narrowed down to a location.reload() call in my production Angular component code that was causing the issue.
So let’s jump into how to handle a location.reload() in our production code from our tests. Note: I did not want/need to test my location.reload(), I just wanted to get past it, essentially ignore it.
First off, we need to move our location.reload() call, from our production code, into its own function. We do this because it makes it MUCH easier for us to stub out a component level function in our test. So here we made a simple reloadPage function.
Next up, we go to our tests. I am assuming you already have your tests set up, most importantly getting an instance of your component under test. We can now reassign our reloadPage function to an empty function.
In the above code, we are stubbing out or overriding the function reloadPage from our component. In this test, reloadPage no longer calls location.reload(). It will call our empty function instead, thus doing nothing. We have essentially remove the location.reload() call from this test or more appropriately stubbed reloadPage out.
Again Note: In my situation, I did not want/need to test location.reload() with this test. I simply wanted to get past it, essentially ignore it.
After making these changes, the tests ran as expected. No more 1505 out of 490 tests. I hope this helped and if it did leave a comment!
A value cannot be null unless it has specifically been assigned null. Let’s look at some code:
Above, on line 1 we are setting our value to null. null is powerful and something commonly found in code. There is even a null object design pattern.
“A variable that has not been assigned a value is of type undefined” (Docs). If we declare a variable but do not assign a value to it, its value is undefined.
Since we didn’t assign a value to temp on line 1 it is undefined.
“A method or statement also returns undefinedif the variable that is being evaluated does not have an assigned value.” So we would see undefined if we access a property on an object that does not exist or does not contain a value.
We don’t need to be scared of undefined it just means the variable has never been assigned or does not exist.
null vs undefined equality gotcha
There is a bit of a gotcha when thinking about equality of null vs undefined. Let’s look at examples:
In the first strict equal (===) case, we get false returned. This is because both null and undefined evaluate to false BUT they are different object types. null is of type object while undefined is simply of type undefined.
That is why the second case of only loosely equal (==) we get true coming back. It’s important to realize the distinction that null & undefined are different types.
Having come from a .NET background I had not seen undefined before. With a little research and playing around with code, it all came together. I encourage you to open up your console window now and mess around a little with null and undefined!