Finding your way around the maze that is JavaScript testing can sometimes be difficult. There are unit tests, integration tests, functional tests, E2E tests, browser tests… With so many buzzwords, who knows what they do and which one to use, what for, and when?
To help with that problem, in this article I’ll give you a guide comparing the different kinds of testing types available, and some recommendations for their use.
Ajax requests can easily go wrong. You can’t guarantee the connection and the server always work correctly. They are also often used to send user input to the server and back, so it’s vital the data is handled correctly.
But testing them can be tricky. It’s asynchronous, and also a good unit test must be isolated, so how can we do that when the code talks to the server?
Let’s take a look at some examples to learn how to test Ajax requests with ease.
I recently wrote about using ESLint to auto-detect bugs. But what makes ESLint the best tool for this job?
There are three other popular JavaScript linters:
What are their pros and cons? How do they compare against ESLint?
When you’re just getting started with automating your JavaScript testing, there’s a lot of questions. You’ll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them?
I’ve talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let’s take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.
I’ve been programming JavaScript for 15 years or so, and I still keep making various silly mistakes – I type things wrong, I forget to rename everything, I forget to follow the coding styles… then I waste my time clicking around in the browser and feel like slapping myself.
Thankfully tools like ESLint exist. ESLint helps by finding errors automatically, so you can spend your time doing something more interesting.
Let me show you a real-world example from a codebase I worked on of how ESLint can help.
I have a nodejs app where I wanted to unit test some HTTP requests. Node usually makes things simple, so I expected this to be like that too… but I soon discovered that this was not the case at all.
When unit testing, you don’t want HTTP requests to go out and affect the result. Instead you create a fake request – a test double – to replace the real one, but because node’s streams are hard to fake, this is where I hit the wall.
It took some work, but I found a way to make it simple! Let me show you how with some examples based on real live production code.
JavaScript has some of the strangest errors. Undefined is not a function? Ugh.
I wrote an article talking about JS errors and a guide on how to fix them on David Walsh’s blog, you should go check it out!
You’ve probably seen people talk about the features in JavaScript’s 6th edition, ES6, or ECMAScript 6. Promises, let keyword, iterators, etc.
But why should you care? I certainly heard a lot about it, but I hadn’t looked into it because I wasn’t interested in theory, but rather the benefits I would get in my day to day work. Is it just feature-bloat for sake of having fancy things in the language, or are they actually useful?
I then did some research and discovered a number of very useful features in ES6 that you can start taking advantage of right now. Let’s take a look at the most useful ones
Note: Post updated for best practices in 2017!
When you want to use ES6 you’re faced with a list of questions: Transpilers, shims, browser support…
In this article, I’ll give you a detailed guide on making sure you get started with ES6 the right way, and instructions on how you can set up a workflow for using ES6 in production easily.
Isn’t it fun to find a comment in code that’s completely out of place and useless? What if you could write fewer comments and still keep the code easy to understand?
One of the primary ways to do this is making your code-self documenting. When code is self-documenting, it doesn’t need comments to explain what it does or its purpose, which is great for making the code easier to maintain. As a bonus, with fewer comments, it’s less likely they’ll be crap!
In this article, I will show you several ways you can make your code document itself.