
Automated testing is something that I've always found particularly interesting. In fact, it's a topic that I've even done a few [talks](https://jonbellah.com/speaking/) and written a few [articles](https://css-tricks.com/visual-regression-testing-with-phantomcss/) on in the past.

React testing (and JS testing, in general) is an incredibly broad topic with a lot of nuance. So, in this post, I'd primarily like to focus on exploring some of the basic "what's" and "why's" of testing React applications with Jest, then finish off with a few best practices.

While this post is an introduction, it does assume that you have some familiarity with React and general testing procedures.

### Why Jest?

If you happen to have tried Jest in the past, particularly prior to version 15, you may have been turned off by the fact that it auto-mocked modules by default (meaning Jest automatically stubbed out functionality with mock data); or that it was rather slow once a test suite reached a decent size.

Fortunately, thanks to a ton of hard work from hundreds of contributors, that's no longer the case.

There are a few reasons that I think Jest is an excellent choice for your test framework:
- **Simple configuration** - it works out-of-the-box for React projects
- **It's fast** - Jest parallelizes tests across workers, spinning up workers asynchronously to read the filesystem and executing them synchronously
- **Snapshots** - even though we don't cover them in this post, I'm a big fan of snapshots. I think snapshots solve a lot of the problems that were virtually unsolveable with visual regression testing (such as false positives from things like sub-pixel differences between machines, OS's, and browsers)

### Jest with Enzyme

[Enzyme](http://airbnb.io/enzyme/) is a JavaScript testing utility built by the team at Airbnb. It's specifically built for React, relying on React TestUtils under-the-hood, but is not specific to Jest; in fact, it also works with other test frameworks like Mocha, Tape, and Karma.

Enzyme isn't a requirement for working with Jest, but without it we would be using the built-in React TestUtils, which include super memorable methods like `scryRenderDOMComponentsWithClass()` and `findRenderedDOMComponentWithClass()`.

Enzyme allows us to test our components in a few different ways, using `mount()`, `shallow()`, and `render()`.

The two most important, in my opinion, are the `mount()` method, which renders our React components in memory using [jsdom](https://github.com/tmpvar/jsdom), or the `shallow()` method, which allows you to render components "one level deep".

Enzyme and Jest allow us to do things like simulate clicks or other DOM interactions, test Redux actions, inspect the props that our React components receive, and a host of other useful things.

### Shallow Rendering

At present, the React core team [recommends using shallow rendering](https://discuss.reactjs.org/t/whats-the-prefered-way-to-test-react-js-components/26/2) to test components. Shallow rendering is a pretty inexpensive process and allows you to isolate components and their immediate children, in order to test each component on its own.

> Tests are executable documentation. What we've started doing is moving tests and the results to the documentation, so you can verify the examples you show in documentation are exactly the code that runs.
> <cite>[Max Stoiber](https://www.youtube.com/watch?v=59Ndb3YkLKA)</cite>

So let's take a look at a basic example of shallow rendering:

```js
import { shallow } from 'enzyme';

describe('<SampleComponent />', () => {
  it('should render three <Foo /> components', () => {
    const wrapper = shallow(<SampleComponent />);
    expect(wrapper.find(Foo)).to.have.length(3);
  });

  it('should render a `#nav-toggle`', () => {
    const wrapper = shallow(<SampleComponent />);
    expect(wrapper.find('#nav-toggle')).to.have.length(1);
  });
});
```

One thing worth noting is that since shallow rendering is such an inexpensive process, there's no real need to render our wrapper in the upper scope of the suite and pass it down to each assertion. Instead, we can just throw away the component after each assertion so we fully isolate each test case.

### Testing DOM Interactions

To test DOM interactions, I would recommend using a library like [sinon](http://sinonjs.org/) to add spies to your test suite, which allow you to test whether a function was called during a particular interaction. 

```js
import { mount } from 'enzyme';
import sinon from 'sinon';
import Foo from './Foo';

describe('<Foo />', () => {
  it('calls componentDidMount', () => {
    sinon.spy(Foo.prototype, 'componentDidMount');
    const wrapper = mount(<Foo />);
    expect(Foo.prototype.componentDidMount.calledOnce).to.equal(true);
  });

  it('allows us to set props', () => {
    const wrapper = mount(<Foo bar="baz" />);
    expect(wrapper.props().bar).to.equal('baz');
    wrapper.setProps({ bar: 'foo' });
    expect(wrapper.props().bar).to.equal('foo');
  });

  it('simulates click events', () => {
    const onButtonClick = sinon.spy();
    const wrapper = mount((
      <Foo onButtonClick={onButtonClick} />
    ));
    wrapper.find('button').simulate('click');
    expect(onButtonClick.calledOnce).to.equal(true);
  });
});
```

By going this route, you can separate your functional/acceptance test from your unit test. You can first test that a function has been called, then separately test that the called function returns expected values.

Sinon can also be used to provide DOM interaction testing with shallow rendering, where you would otherwise be required to use `mount()` and simulate interactions with jsdom.

```js
import { shallow } from 'enzyme';
import sinon from 'sinon';

describe('<SampleComponent />', () => {
  it('simulates click events', () => {
    const onButtonClick = sinon.spy();
    const wrapper = shallow(<Foo onButtonClick={onButtonClick} />);
    wrapper.find('button').simulate('click');
    expect(onButtonClick.calledOnce).to.equal(true);
  });
});
```

The above two code samples come from the [Enzyme docs](https://github.com/airbnb/enzyme), which I highly recommend taking a read through.

### Summary

Jest and Enzyme make testing React applications an absolute breeze... but we've only really scratched the surface of what they can do. We've not yet covered unit testing, snapshot testing, full DOM testing, or any of a handful of other tools and methodologies that we have at our disposal.

Next time you spin up a new React project, be sure to consider Jest for your test framework.

Intro to Testing React Applications with Jest and Enzyme


Welcome to the new digs!

This past weekend, I finally decided it was time to refresh things around here. Despite the fact that I still felt the old design *looked* pretty good, I didn't feel that the underlying technology and overall feel were particularly reflective of how I (or, increasingly, anyone) build sites these days.

I figured I would take an opportunity to walk you through the various updates and decisions that were made during the process.

### The Platform

On the old site, I was using a pretty basic WordPress theme that I'd built from scratch. I took a good bit of care to ensure it was lightweight and performant, achieving sub-500ms render times over a cable connection, but that was really the only remarkable thing about it.

Over the past year or so, I've spent a significant amount of time working with React and have really come to love the experience of building sites with it. So, when it came time for this redesign, I knew where I wanted to start.

I thought briefly about building a WordPress theme that was powered by React and the WP REST API, but decided that I would rather manage a blog about code like I would manage any other code.

After a bit of research, I came across [GatsbyJS](https://www.gatsbyjs.org/), a static site generator for React.

Spoiler alert: It's awesome.

For the last few days, I've been tinkering and building out this site, while learning more and more about Gatsby. I have been really impressed by so many of the features: it has a simple plugin to generate an RSS feed, it handles server rendering out-of-the-box, routing is an absolute breeze, etc.

The thing that probably impressed me the most, though, was the fact that the only thing I needed to do to make the site fully compatible with Google's [Progressive Web App Checklist](https://developers.google.com/web/progressive-web-apps/checklist) was add a `manifest.json` file.

### The Migration

Gatsby actually provides a [plugin](https://www.gatsbyjs.org/packages/gatsby-source-wordpress/) that enables basic support for using WordPress as a data source. Ultimately, though, I decided that I would rather start writing posts in markdown and storing them in my repo, making it easier to track changes and to allow others to collaborate and comment on the things that I write.

Fortunately, my history of infrequent writing paid off for once. I used this [HTML to Markdown](https://domchristie.github.io/to-markdown/) converter to take old posts, convert them to markdown, and do a bit of cleanup. It was a super manual process (and totally not scalable), but I didn't have that many posts to bring over. 

I did make a bit of a controversial decision during this process and only brought over a relatively small subsection of posts. There were a number of posts that I felt were either outdated, irrelevant, or no longer reflected my opinions about code. I'll be working to update many of the posts that I did bring over to be more complete and correct inaccuracies. 

### The Hosting

Based on recommendations found in various places during my time researching Gatsby, I decided to take a look at [Netlify](https://netlify.com). 

I went back and forth between `gh-pages` and Netlify, but decided to go with Netlify primarily due to the fact that I needed to handle redirects for the aforementioned retired posts and didn't want to manage that with React routing. 

Thus far, I've been rather pleased and impressed with the service. Setting up the new site was super easy (authenticate the GitHub repo and go). Netlify handles pretty much all of the deployment configuration for you and uses git hooks to detect updates on your chosen branch.

On the free tier, I'm still provided SSL (by way of Let's Encrypt), a CDN, automated deploys, and a few other handy features.

### The Code

As a final note, I have decided to open source the code that powers [this site](https://github.com/jonbellah/jonbellah.com). Please feel free to poke around the codebase or fork it for your own use.

If you have any questions, comments, or want to share what you've done with your fork, I'd love to hear from you in the Issues section on GitHub!

Introducing a Fresh New Look


I had the privilege of attending [jsDay](https://2017.jsday.it/) last week in Verona, Italy. One of my favorite talks during the two-day event was titled "CS101 Intro to Computational Complexity: The Sorting Problem" by [Claudia Hernández](https://twitter.com/koste4).

When calling `Array.prototype.sort()`, I (as I suspect many of you) had no idea exactly what the magicians under-the-hood were doing with my array. All I knew was that if I didn't pass proper instructions to the method, I didn't always get back the results I was expecting.

The crux of the talk revolved around the various different sorting algorithms that each of the major browser vendors use (MergeSort, QuickSort, and InsertionSort) for the native `.sort()` method and how each of those algorithms perform under various different conditions (sorting an array of 10 items, 100 items, etc. up to 10 million items).

I highly recommend taking a look through [the slides](https://speakerdeck.com/claudiahdz/cs101-intro-to-computational-complexity-the-sorting-problem). I'll be sure to update this post if/when a video of the talk becomes available.

JavaScript Sorting Algorithms


Lately I've found myself working with an ever increasing number of WordPress multisite installations, each built with a slightly different approach than the others. As a result, I've spent a lot of time thinking about how to architect these networks to maximize code clarity and maintainability.

Before going much further, I should point out that in my particular use cases, the individual sites on each of the networks generally share common designs, templates, general features, etc.

There are, however, minor customizations to each site - an additional widget here, additional templates there, and so on and so forth. If you've worked with WordPress in the past, you may be familiar with `add_theme_support();` it's used to register support for things like post thumbnails, title tags, custom headers, etc.

You may not be familiar with `current_theme_supports()`, though. `current_theme_supports()`, in conjunction with `add_theme_support()` and `remove_theme_supports()`, make up the Theme Features API and provide developers with an excellent API that, in practice, allows us to bundle features in a modular way that can easily be enabled or disabled programmatically, on a site-by-site basis.

> **Theme Features** is a set of specific functionality that may be enabled by theme authors. Themes must register each individual Theme Feature that the author wishes to support.<cite>[WordPress Codex](https://codex.wordpress.org/Theme_Features)</cite>

The approach that I've come to favor uses the Theme Features API to break a codebase into three distinct pieces: a feature plugin, a theme, and child themes.

### The Plugin

The feature plugin should be enabled network-wide, whether as an `mu-plugin` or just enabled from the network panel in the WordPress admin. All primary pieces of functionality should be placed in the plugin. Let's say, for example, that we have a custom popular posts widget that we want to enable. In our feature plugin, we can write all our code in a file called `popular-posts`. Then conditionally load that file like so:

```php
if ( current_theme_supports( 'my-plugin', 'popular-posts' ) ) {
    require_once( esc_url( plugins_url( 'includes/modules/popular-posts/popular-posts.php', __FILE__ ) ) );
}
```

### The Parent Theme

In most of my own use cases, the sites on the network shared some sort of common design elements. In these cases, it made sense for us to have a parent theme that we could use as a starting point for each site, then extend and customize as needed.

If the sites on your multisite network do not have these commonalities, you can skip the parent theme. If the sites on your multisite network _do_ share similarities, then leveraging a parent theme makes a lot of sense. Another great thing about leveraging a parent theme is that when you need to customize it for a particular site, you can write your own hooks with `apply_filters()` or `do_action()` and then extend those customizations in your child theme. That way each site on the network can display the same piece of functionality in many different ways.

Let's say, for example, that on **Site A** you label the popular posts feature "Popular Posts", but on **Site B** you label it "Most Popular". In places where you're outputting the title of your popular posts widget, you can use:

```php
echo apply_filters( 'popular_posts_title', esc_html__( 'Popular Posts', 'textdomain' ) );
```

With this architecture, I've also found it useful to leverage the WordPress Customizer for things like logos, color settings, etc. and providing default values for each setting. This makes it especially easy as a new developer on a project to spin up an environment without requiring an exact copy of the production database, as basic settings and features will be enabled and configured programmatically.

### The Child Themes

Finally, having an individual child theme for each site on the network provides you a place to put all of your site-level customizations. The primary function for us will be to enable selected features from our feature plugin. In our `functions.php` file, that would look something like:

```php
function theme_supports() {
    add_theme_support( 'my-plugin', array(
        'popular-posts',
         'my-other-feature'
     ) );
}
 add_action( 'after_setup_theme', 'theme_supports' );
```

### Final Thoughts

If you've ever ramped up on a new WordPress multisite project, you probably understand how difficult it can be to discern where all of the code you're working on is being used, particularly if features are being enabled as standalone plugins; so often test cases get missed and bugs get shipped.

By enabling and disabling features programmatically, we can more easily determine which sites on a network are utilizing a particular feature. I believe this architecture provides a clean code structure and clear separation of concerns, making future maintenance a much less daunting task.

Now, when needing to do maintenance on a feature in six months, it will be easy to discern which sites a particular feature is enabled on just by searching the project directory - as opposed having to hunt through each site to see if the feature plugin is enabled.

WordPress Multisite Architecture with the Theme Features API


I review a _lot_ of code. That experience has given me an interesting insight into the approach and thought process of many, many other developers. I often run across code where developers are mixing the responsibilities of their HTML, CSS, and JavaScript, making their code difficult to update or build upon. 

The term _separation of concerns_ has been around for a quite some time, [more than 40 years, actually](https://en.wikipedia.org/wiki/Separation_of_concerns#Origin). In short, separation of concerns is a guiding principal in software development centered on the idea that programs should have distinct sections, with each section being responsible for its own concern.

A _concern_ is a very broad term that can refer to just about anything that relates to a website or other piece of software. In this case, we're going to be talking specifically about the roles and concerns that each language should have in the front-end stack. By separating concerns between languages, you can drastically improve both the quality and maintainability of a project.

### Separating HTML and CSS

A common issue I've encountered is developers using presentational classes in their markup. A presentational class is any CSS class that is used to define the look or feel of a particular element or component, but is not descriptive of the actual element or component.

For example, much of Bootstrap relies on presentational classes, which is especially evidenced in the grid system.

```html
<div class="my-element col-lg-3 col-md-4 col-sm-6 col-xs-12">
```

Now, as you see, your markup is not only defining _what _your element is, but also how it looks. That's CSS territory.

Rather than using presentational classes, why not use Sass mixins?

```html
<div class="my-element">
```

```css
.my-element {
    @include col-lg(3);
    @include col-md(4);
    @include col-sm(6);
    @include col-xs(12);
}
```

This approach accomplishes exactly the same thing, but keeps your HTML descriptive of the document and your CSS squarely in its own lane.

### Separating CSS and JavaScript

Another common issue that I've encountered is CSS classes being too tightly coupled with JavaScript targeting and manipulation. Have you ever changed a class (say, to be more semantic) only to realize that it broke a bunch of other stuff?

There a couple of ways that I like to separate CSS and JavaScript.

First, when I target an element, I generally prefer to target an ID (if possible)... and I prefix that ID with `js-`. This will always signify to me, or anyone reading through my code, that an element is being targeted with JavaScript. I also never attach styles to the prefixed classes.

In practice, this would look like:

```html
<div id="js-my-element" class="my-element">
```

or

```html
<div class="my-element js-my-element">
```

### Putting It All Together

With this approach your HTML, CSS, and JavaScript all play their own, clear roles. They do not overlap in their responsibilities and your code ends up being more semantic and flexible; making your application significantly easier to jump into and maintain.

Separation of Concerns


I'm a big fan of side projects, they're my favorite way to teach myself new things, like trying a new language or framework. Up until recently, I've never been great at launching my side projects, though... they were always something I just toiled away with until I had the knowledge I wanted, then I'd ditch them.

A few months ago, my wife and I were sitting around talking about some ideas for a new side project that we could work on together. It was the first time we were going to be working on a project together, so we wanted to make it about something that we really enjoyed. We weren't exactly setting out to disrupt an industry.

At the time, I was also really interested in learning more about how to implement Elasticsearch (via ElasticPress). I am always trying to push myself beyond just the standard front-end stack, so that I can better understand how everything works together.

### Choosing a Side Project

Out of those discussions was born [HikeColorado.org](https://hikecolorado.org). It's the perfect marriage of our passion for hiking and photography, with my desire to learn something new.

Now, the funny thing is that we ended up building and launching the site and I've still not yet gotten Elasticsearch implemented. I ran into a bunch of little issues with box permissions and things (my DigitalOcean box actually got locked because they suspected I was using it for spam... Needless to say, I'm not exactly a systems engineer) but it's still on my 'to do' list.

Shortly after we launched, [Justin](http://justrunyon.com) (who has been my best friend since 6th or 7th grade) joined us as a writer, because he's also an avid hiker and backpacker.

I signed up for a few affiliate programs and let it run. While it's still not earning any money, traffic is starting to grow.

### Continuing to Learn

After we launched that site, we started thinking 'well, we love snowboarding, too!'

I've also been really keen lately on learning React... so we set off on a path to build a new site, dedicated to skiing and snowboarding, that is entirely powered by a single-page React application.

The new site, which will be launching in the coming weeks, was an opportunity for me to learn more about combining the WordPress REST API with a single-page application. The site uses WordPress, set up on a subdomain serving up the necessary endpoints, with a super snappy React experience. I'll be writing more about the process of building that site soon.

### Learning the Lesson

Don't be afraid of side projects... they're an excellent opportunity to learn. Some of the most valuable of the things that I've learned in my career have been learned through side projects.

My old WordPress theme shop started as a side project, taught me a ton about WordPress, ended up [getting bought out](https://upthemes.com/blog/2014/06/acquisition-announcement-lucid-themes-theme-collection/), and was a big contributing factor in my ability to land the job I have now.

Side projects may not always be immediately profitable, but the investment in teaching yourself new things will always pay off in the long run.

Articles

Intro to Testing React Applications with Jest and Enzyme

Introducing a Fresh New Look

JavaScript Sorting Algorithms

WordPress Multisite Architecture with the Theme Features API

Separation of Concerns

Turning Passions Into Side Projects

Intro to Testing React Applications with Jest and Enzyme

Introducing a Fresh New Look

JavaScript Sorting Algorithms

WordPress Multisite Architecture with the Theme Features API

Separation of Concerns

Turning Passions Into Side Projects

Like what you've read?