I was just on vacation for four weeks and I spent the entire time writing code.
Quick JavaScript testing tip: How to structure your tests?
Something that’s not talked very often when it comes to writing unit tests is how should you structure your test code?
I’m not talking about “well, just put your code into a file in test/SomeTest.js”, but rather, how should the test code itself within your test case be structured?
While it may feel inconsequential – afterall, it’s just a test, and it’s probably just a few lines of code – it’s actually very important to take care when writing your tests. The most annoying piece of code to fix or work with is the code you can’t make any sense out of. Tests are code. As such, it’s important to treat your test code just like any other code, and make sure it’s easy to understand!
Let’s take a look at how we can structure our test code to make sure our tests are easy to understand and follow.
JavaScript Testing Tool Showdown: Sinon.js vs testdouble.js
When unit testing real-world code, there are many situations that make tests hard to write. How do you check if a function was called? How do you test an Ajax call? Or code using setTimeout? That’s when you use test doubles — replacement code that makes hard to test things easy to test.
For many years, Sinon.js has been the de-facto standard in JavaScript tests for creating test doubles. It’s a must-have tool for any JavaScript developer writing tests, as without it, writing tests for real applications would be nigh impossible.
Recently, a new library, aptly named testdouble.js, has been making waves. It boasts a similar feature set as Sinon.js, with a few differences here and there.
In this article, we’ll look into what both Sinon.js and testdouble.js offer, and compare their respective pros and cons. Will Sinon.js remain the superior choice, or will the challenger take the prize?
Note: If you’re unfamiliar with test doubles, I recommend reading my Sinon.js tutorial first. It will help you better understand the concepts we’ll be talking about here.
230 Curated Resources and Tools for Building Apps with React.js
This post will curate the best resources, tools, libraries, and articles that will help you learn to build production applications with React.js. This 6000 word post will take you from getting started with React, through UI design, routing, testing, deployment, and continuous integration. There are many sections and you should feel free to jump to the resources you need.
Simplify your JavaScript code with normalizer functions
Everyone loves a good if-else tower! What could be simpler than nesting a few conditionals?
if(stuff) { if(more stuff) { haha(); } else { cool(); } } |
Ok – that isn’t the most amazing thing in the world.
In a simple example like this, it isn’t too bad. But we all know real code is never easy to understand, especially after ten different people have changed it over the course of years!
But what can you do? Sometimes you have complicated logic, and implementing it without a leaning tower of if-elses can be nigh impossible.
Let me show you something called normalizer functions, and how they can help you get rid of some of that complexity.
4 non-JavaScript library topics to learn to take your skills to the next level
Every new year there’s always a bunch of articles about “Learn this in year 200X!”
But the problem is.. they’re always about libraries. Learn PrototypeJS. Learn jQuery. Learn Backbone. Learn AngularJS. Now it’s Learn React (or some React-derivative)
This stuff comes and goes!
Chances are, your job mostly dictates the libraries you’d use. Even if you do get to pick one, you’ll figure it out with your coworkers based on factors other than “some guy on the internet said we should use this”.
I’m not saying those articles are necessarily bad. They can be a useful look at what’s popular and what are some new interesting up and comers.
What I am saying is there are more useful things to learn beyond the cool library of the year.
Best practices for JavaScript function parameters
From time to time, people ask things like “should I use objects to pass function arguments”. I’m sure you recognize the pattern, as it’s common with many libraries:
$.post({ a: 'lot', of: 'properties', live: 'in', here: 'yep' }) |
But I would say this is not actually such a good idea.
Let’s take a look at the best practices for defining function parameter lists in JavaScript.
5 step method to make test-driven development and unit testing easy
What’s the hardest thing in test-driven development or unit testing in general?
Writing tests!
The syntax or the tools aren’t the problem – you can learn those enough to get started in 15 minutes.
The problem is how to take some vague idea in your head about what you want to do, and turn it into something that verifies some function works… before you even wrote the damn thing!
People tell you to use TDD. But how can you possibly write a test for something that doesn’t exist? I don’t even know what the function is going to do yet – or if I actually want two functions instead of one – and instead you want me to think of a test for it? Are you crazy?
How do all those people who tell you to use TDD do it?
That’s the thing – test-driven development requires thinking of your code in a different way. And nobody ever tells you how to do that.
Until now.
What is property based testing (and how to do it in JavaScript)?
Ever wonder… what if you didn’t have to write specific tests with hardcoded test data?
Or have you ever written a function which can take many different values as input? How can you test something like that easily with different values?
These are the kinds of important questions in life that keep me up at night! (ok maybe not)
But did you know both of these questions can be solved with something that’s called “property based testing”? That’s right – property based testing can help you test the untestable. And while at it, you can even use them to test your other functions with automatically generated data.
All of this means property based tests are great for finding those pesky corner cases that are easy to forget. This means less debugging weird bugs that you find in production – you know, the really hard to reproduce ones, which occur for only one user in some weirdly specific combination of settings.
Sounds pretty cool huh? Let’s find out some more!
Staircase code – how short functions are not always the best solution
Have you ever seen code which at first look seems good.. but then as you try to figure it out (maybe to fix a bug), it just feels… wrong?
For some reason the code just feels really difficult to follow – for no obvious reason!
In this post, I’m going to explain one such occurrence that I ran into in a production codebase. The code looked ok, yet it was hard to understand. Why?
Let’s find out. We’ll also look at some examples of how you can avoid and discover problems like this more easily.