node.js testing, error handling, and a bit about the node.js cluster module
Tell me about a project you’re particularly proud of. What did you do that worked out well?
in this project i plugged into a Marvel API to create a pretty snazzy superhero search engine. given how wet behind the ears i was (and am) almost anything that ended up actually working or showing up as expected made me particularly proud. i still haven’t figured out how to use dotenv to hide the API key without breaking the rest of my code, so i still haven’t uploaded the code to github, but i was able to get google cloud platform to actually host it successfully, which was another win for a newb like myself.
note: the above link may or may not still refer to the Marvel API, as i may need to use the google cloud bucket for another project. i will make (dubious) attempts to update the link, or at least update what the link actually refers to, as it may be a newer project i am even more particularly proud of. 😊
How do you do testing, and what do you think about it? How would you improve QA?
to “do testing” you might create dummy data, stubs, dummy outputs, and use these as templates to write development code that can ramp up to production-ready code by transporting it on these “training-wheels” in order to verify each step as you work your way up from the weeds through the valleys to the hills and with hard work and some luck, the mountains. (yes, that was a run-on sentence.)
testing becomes more important the more you scale up, as changing one single feature of a giant codebase could very feasibly break if not one thing somewhere, many things in your software (see that wordplay?). you wouldn’t want to update an anchor tag and then break your Nav UI in the process. and you definitely wouldn’t want to update a single anchor tag and then have to check every single functionality of your giant website or app. this is where a steadily maintained test pyramid (more on this in my next blog) comes in very handy, as it can automatically test each functionality from the ground up every time you rebuild and redeploy your codebase after each push.
QA is corporatespeak from where i’m sitting; tools for the big dogs. on my personal scale of operations, QA and testing is common sense and case-by-case. but from the upper floors of large glass buildings, QA improvements might look more like this:
What tools do you use to find a performance bug?
the following is ripped straight from
https://www.edureka.co/blog/performance-testing-tools/:
Load testing — It checks the application’s ability to perform under anticipated user loads. The objective is to identify performance bottlenecks before the software application goes live.
Stress testing — This involves testing an application under extreme workloads to see how it handles high traffic or data processing. The objective is to identify the breaking point of an application.
Endurance testing — It is done to make sure the software can handle the expected load over a long period of time.
Spike testing — This tests the software’s reaction to sudden large spikes in the load generated by users.
Volume testing — Under Volume Testing large no. of. Data is populated in a database and the overall software system’s behavior is monitored. The objective is to check the software application’s performance under varying database volumes.
Scalability testing — The objective of scalability testing is to determine the software application’s effectiveness in scaling up to support an increase in user load. It helps plan capacity addition to your software system.
honestly, i’m not sure they should be called performance bugs, since a bug tends to be a mistake in code. performance “bugs” are probably better described as performance bottlenecks; they are more about inefficiency and failure to optimize — or at least opportunity to optimize.
if you are interested in the actual leading tools for performance testing, click on the link at the beginning of this question/answer. it has the top 10 performance testing tools, and very good descriptions of each. just scroll down a bit, you’ll find it easily (JMeter is number 1).
What is the preferred method of resolving unhandled exceptions in Node.js?
well the preferred method would be to handle your exceptions. but if you do have an unhandled exception, you might use a try/catch block. even better though, is to use the built-in node.js Process module. basically, if an uncaught exception occurs, the following block will handle it:
process.on(‘uncaughtException’, function(err) {// handle the error safelyconsole.log(err)})
How does Node.js support multi-processor platforms, and does it fully utilize all processor resources?
the node.js cluster module allows the developer to utilize however many cores the host machine’s cpu (processor) has, to run an instance of your server in each one — thereby fully utilizing all processor resources. each of these instances is known as a worker process (or a worker thread as it is known in node.js).
Even though node.js is single-threaded, the cluster module allows you to execute that single thread, in multiple instances.
for each core the host machine has (most machines have at least 2, many have 4 and some up to 32) this single thread (which is just a virtual core) can be repeated — as an instance — multiple times. this method of optimization allows for some insane scalability.
What is typically the first argument passed to a Node.js callback handler?
an optional error object. this way, any function that fails can be handled appropriately:
function callback(err, results) {
// usually we'll check for the error before handling results
if(err) {
// handle error somehow and return
}
// no error, perform standard callback handling
}