JavaScript Unit Testing, Standards and Maintainability

This week has been an exciting journey into unit testing, this time starting to write my own (with guidance and a lot of trouble-shooting). I have also been reading more into standards, this time more than just accessibility standards set by W3C. So here’s what I have to show for another week of Google, Stack Overflow, coding night classes, and thankfully very helpful cohort.

Unit Testing Adventures using Node.JS

I am working on figuring out how to write edge case unit tests in node.js (using Mocha). It is not so difficult to think of basic edge cases, however the actual writing of the tests can be trickier. Although the tip to write unit tests prior to diving into the code has been a helpful mentality. It is one that will take me a while to fully adopt, since habit forming takes time and consistency, but it should also make my code cleaner, more efficient and help me to continue to develop good habits now that I am learning to work in a test-driven development environment.

It is nice to see those little green checks that say at least part of my code works!

Illustration of green checkmark and red “x”
Image by Open Clipart-Vectors on Pixabay

What is this whole “use strict”; thing? Why and maybe why not to use it…

“Use strict” helps to negate potential compatibility issues when using JavaScript. Because JavaScript is robust and has evolved a lot over time and,

“any mistake or an imperfect decision made by JavaScript’s creators got stuck in the language forever.

This was the case until 2009 when ECMAScript 5 (ES5) appeared. It added new features to the language and modified some of the existing ones. To keep the old code working, most such modifications are off by default. You need to explicitly enable them with a special directive: "use strict".” (

“use strict” can be beneficial by helping to ensure cross-browser compatibility. However, it changes syntax and runtime behavior. It converts mistakes into errors, which means it is beneficial for us junior developers since these mistakes are converted to errors and it break the code. Therefore, when doing unit testing, it is a good way to quickly find these mistakes and fix them.

However, for more seasoned developers, this could be a drawback, since these small mistakes that are semantic but still would run in a real-time environment it can be frustrating and possibly lose momentum with increased frustration.

Here are some helpful links that broke down “use strict” in a very comprehensive manner:

Hoisting in JavaScript.

Hoisting in JavaScript is similar to it’s more utilitarian meaning. To “hoist” is to raise or haul up, often using ropes, pulleys, or your own strength (e.g., hoisting the mast on a ship, he hoisted the suitcase into the car).

So in JavaScript, when we say “hoisting” we mean that wherever we write or declare a variable, it can be used or pulled from. Therefore, we can use a variable prior to it being declared.

Here are some docs for good review:

Ship with full mast sailing on the water
Image by Peggy Marco on Pixabay

Why do we have standards and standards bodies like ECMA and W3C?

Sorry internet cowboys, outlaws or whatever you call yourself while coding late into the night… in this case, standards and standard bodies are important.

Think about it as the fact that standards, especially when it comes to an international and almost universal medium for creation, information dissemination and global networks, such as the internet and web content is very important so that anyone working on web development, software development, hardware, etc. can successfully communicate, share knowledge and allow for the successful translation between languages. Essentially, JavaScript developers in different countries, even if their native language are different, should be able to understand each other’s code.

Standard bodies like ECMA and W3C are important because they have global members who work to uphold and focus their research into issues of significance for large-scale topics, such as accessibility, language integration, etc.

Here are some additional links for contextual information:

Image by James Markosborne on Pixabay

Okay, so now what have I actually done to start increasing my own code maintainability in recent projects?

I am working towards improving my own code writing maintainability by trying to keep out anything too fancy, by writing out comments to organize the code and help me to track my line of thinking. I also am working to re-read my past coding projects (cringe) and learn from what I had coded (and not commented out well) a month ago. By looking back, I am reflecting on how far I have come in my coding, but also getting a better feel for if I were a developer who had never seen my code before, what questions would I ask?

This reflection is helping me to make small improvements to how I go about writing code and more importantly, what I do and do not comment out in the code I am now writing.

Why is it, in general, a good idea to leave the global scope of a website as-is and never touch it?

Global variables in JavaScript are dangerous because if you change it in one location, it can break the code in other areas you likely did not foresee.

All code shares a single global namespace, so it you start changing the global scope, it can change other areas you did not intend to change.

I hope this helps to clarify any of some of the likely points that will come up in some (hopeful) future junior developer job interviews for both myself and anyone else. Now back to researching and practicing ALL THE THINGS!

Your friend in code,


I am an avid adventurer taking readers on my latest journey in learning to code. Let’s get started from 0 experience to programmer!

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