ECMAScript and Test Suites

In my next episode of open source adventures, I was introduced to open standards and running test suites. So I do know what open source but I have no clue what are open standards. Well open standards are the guidelines or rules that define what can be open and distributed in the open source community. So a better way of thinking about this is laws put in place by contributors themselves to ensure that the open source community and the global software community has some sort of stability in it.

Now this phrase open standards was completely new to me when I was introduced to it by my professor and a guest speaker, David Bruant. After their explanation, it made a lot of sense because how else would the open source community filter out what is beneficial to the community and what is not? So one of the open standards we were introduced to is the ECMA Standard. This is a standard that is tied to the ECMAScript language. This language is one of the most popular languages in the world and is used in so many different applications such as web browsers.

So what makes this open standard so special? So this open standard defines a language that is widely used and supported that it requires constant maintenance to keep up to date with the changing software environment. It is also strongly tied to the JavaScript language, which is one of the fastest growing languages ever. It is constantly being updated and new features are being added which means ECMAScript and the ECMA Standard has to keep up with it.

Now onto the next concept that was discussed and that is test suites. So test suites are tests that are packaged together, which often check many different aspects of a feature to ensure it works as expected. The test suite of ECMAScript can be seen here. After briefly going through some of the Array.prototype.reverse() tests as instructed by our professor, we came to realize that these tests weren’t robust enough. As good as they may seem, they aren’t the BEST way of doing it. Software development is all about finding the best way to fix a problem rather than just finding the first possible fix. Now onto how I went about improving them.

As you can see, the picture above shows the steps to installing and running these test suites. You also must have npm installed beforehand. When I ran this test suite, 199 tests were successful and 6 failed. The next step was to read up on the Array.prototype.reverse() specs. This can be seen here. After this, I had to analyze the current tests in the ECMAScript’s Array.prototype.reverse() tests which can be seen here. After analyzing the current tests in the S15.4.4.8_A1_T1.js file, I realized that these tests can be improved.

I then analyzed the tests performed in TypedArray.prototype.reverse(), and realized the main difference in testing between these two tests is the use of assert.sameValue(). So after researching assert.sameValue() , I found the ECMAScript test suite had a good definition of the usage of this function right here. Based on their definition, sameValue method can take in two values, it will check if these values are strictly equal to one another, and if not then it will print an error message specified as the third argument.

So what is strict equals?Strict equals has many different definitions based on the types they handle, so in our case I will explain the Object portion. Two objects are considered strictly equal if they are referencing the exact same object. So what does this mean in context with the tests in the files above?

x = new Array(1, 2);
var reverse = x.reverse();
assert.sameValue(x, reverse, “Values are not equal.”);

Well the array x, can only ever be strictly equal to array reverse if they are referencing the EXACT SAME object. This should be the case because array.reverse() returns a reference to the array. This will mean reverse and x should be referencing the same object, meaning this assert.sameValue() method should equate to true.

So I decided to revamp the tests in the S15.4.4.8_A1_T1.js file to utilize this assert.sameValue() method and these tests can be seen here. All in all, this thought me a lot about open standards and how important they are to the community. This also showed me that as good as you think your tests may be, there is always a more robust way of testing your code. Definitely a valuable learning experience and I look forward to my next one! See you on my next blog post!

Software Developer with a passion for Mobile Application Development, Machine Learning, and DevOps.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store