With the boom in JavaScript libraries, frameworks, and people picking this language up, I find common questions every time someone decides to write some tests with JavaScript. Here are some of the most common things I need to do in my tests, and how to do them, across three major tools: Jasmine, Mocha, and Jest.

Run a single test, or suite of tests

Scenario: I’m writing tests and don’t want to run my entire suite of tests across the project. What’s the quickest way to do this?

Mocha

Use only()

describe.only('This describe block will run by itself on test run'...// Or a single testit.only('This it…


Photo by Marvin Meyer on Unsplash

Summary

When you’re on a development team with multiple contributors working on a shared code base, code reviews are an essential tool to ensure consistency and quality across a project. In order to be an effective tool, though, developers need to approach reviewing code with the right attitude. A code review is not a forum to show how smart you are, or an opportunity to push your private agenda for the code base. The last thing you want to do is to tick off your team members when you have an opportunity to help make the code base improve. …


Photo by Tengyart on Unsplash

The fun part of developing applications is seeing new functionality. One of the dark sides is finding that something doesn’t work when you are SURE that it should. Here are some helpful gut checks to check before you spend hours on a bug, and it may help you keep your sanity.

Ensure you’re on the right version

The days of CI/CD are here, but that sometimes means that the latest version of the code isn’t the one that’s already being tested. Often there will be release candidates that are a few versions behind your master branch. …


Photo by Jilbert Ebrahimi on Unsplash

Summary

One of the terms the development community is fond of using is “Code Smell”. A code smell is an indication in code that there may be room for improvement. It does not mean something has been done incorrectly, or is wrong, but rather is a sign that you may want to take a closer look at the thinking that led to code being written a certain way. Often, it’s because there’s an anti-pattern or bad practice in use and while the code or application “works”, it may not be as maintainable or readable as it could be.

For some “smells”…


As you explore different JavaScript frameworks, you’ll notice themes and different flavors in the way each of them address common problems. For front-end frameworks, data-binding is one of the most important tasks that will need to be done. In this article, I’m going to look at how three of the most popular frameworks today handle this, and what you may want to look for when moving from one to the other.

Google Searches over the past 5 years for React (blue), Angular (yellow), and Vue (red)

Various Types of Binding

Most frameworks support dynamic properties and data binding in a few different ways:

  • Interpolation
  • Property binding
  • Custom directives

Angular

Angular was my first love when it came to front-end frameworks…


Photo by Marco Guerrero on Unsplash

Roadmaps have been a centerpiece of product development for a long time, and recent advancements in tooling have put them squarely in the spotlight. Every week seems to bring along another online service meant to build visually stunning roadmaps such as ProductPlan, Aha, and OnRoadmap.

With all the focus on roadmaps, I wanted to take a moment to look through how roadmaps can be used. Depending on your organization and the purpose of the roadmap, the importance of it can be very different, and the messaging to the rest of the organization can be different as well. I’ve found two…


Photo by Christian EM on Unsplash

Developing a product is a balancing act in trying to get the best product you can as quickly as you can. There’s a constant push and pull between management and development in needing more and needing it faster at the same time. To an extent, this is a healthy balance. Many engineers I’ve worked with need a little push to ensure they’re not overthinking a solution, and managers need the reality check a good team will give them when they ask for too much.

The common argument that’s difficult for anyone not on a software team to understand, though, is…


Building a software product well takes an amazing combination of talents from a team of skilled individuals. When you have a passionate group of engineers who want to put out a product they can be proud of, as a product manager you often find yourself doing something you never thought you would do: scaling back the scope of projects.

The stereotypical interaction between a PM (product manager) and a development team is that the PM asks for the world, and the development team argues that they can only give him a city, or even a town.

Just recently I realized…


Photo by Ian Stauffer on Unsplash

Just recently I was put into a role that, 2 years ago, I would have told you I never wanted: Product Owner.

I’ve always been a software engineer. I started my career by being an overachieving developer who wanted to learn as much as he could and make awesome things. I went on to be a full fledged software engineer, lead developer, architect, and then technical lead all in the space of just a few years. …


Tell you what. There’s almost nothing more depressing than looking at your production error logging seeing this:

You think, oh… ok, so we’re not catching errors very well. Let’s pop in to that error and see what’s going on. So you dig in a little big to find:

Chris Hand

Trying to help others avoid my mistakes.

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