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!
What is this whole “use strict”; thing? Why and maybe why not to use it…
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” 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:
Here are some docs for good review:
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.
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:
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?
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,