The main pro of Jest over Mocha and Chai is it requires far less setup. Just install jest into your project and in your package.json

"scripts": {
  "test": "jest",
  "test:coverage": "jest --coverage",
  "test:watch": "jest --watch"
}

Make sure your tests either live in a '__tests__' folder or are named [myfilename].spec.js and jest will just find them and run the tests. If you want to mock a function there's no need to install a mocking library.

const myMockedFn = jest.fn();

You can then run assertions to see if that function was called, and with what arguments amongst other things.

Setting up coverage and other features require quite a lot of effort with Mocha. Jest is also being very actively developed if you look at their repo.

In short it's just very convenient and easy to get up and running with things just working right out of the box, making it ideal for beginners.

 

Take a look at how it's setup in my repository.

@@Jack This might help you with asynchronous testing https://facebook.github.io/jest/docs/asynchronous.html#content

Edited January 30, 20179 yr by rbrtsmith

@@citypaul Jest uses Jasmine under the hood. Although I have read they're working on migrating out from it, apparently it's not so well maintained anymore.

 

I'm not religious about Jest. I just find it the most convenient of the libraries I've tried with. We used Ava on our last project and it was just a bit of a pain to get it all configured to our liking, Jest was much, much simpler in this regard. It does help though because we are using React. I'm just pointing out that while Jest is very well suited to React projects, it does not depend on it.

 

While apart from setup there's no advantage to using Jest on pure JS I don't see any drawbacks to using it either. So if getting up and running quickly is a priority - especially for beginners I think it's a good choice. The revamped docs are also very beginner friendly

Edited January 31, 20179 yr by rbrtsmith

It looks like it grabs the values from Node so you don't have to switch to terminal.

 

https://marketplace.visualstudio.com/items?itemName=prashaantt.node-tdd

https://mobile.twitter.com/

The new Twitter for mobile is built with React and the backend has been changed to Node and Express. Interesting times.

JS scratchpad from the team at Wallaby JS

https://quokkajs.com/

I've been using Jest for a while now and I have to say I'm really enjoying it. I find it's much faster than Mocha/Chai and it's extendable too which means I can create my own methods for validating data.

I've been using Jest for a while now and I have to say I'm really enjoying it. I find it's much faster than Mocha/Chai and it's extendable too which means I can create my own methods for validating data.

 

Glad you like it. I hated it when we first used it in work about 10 months ago, it did lots of horrible things like autoMocking modules, but that's been taken out and lots of good work has been done on it. We decided to try it again in work and will be sticking with it for the foreseeable future now.

 

It was initially aimed at React consumers but it's useful outside of that. We wrap out Nightmare.js E2E tests in Jest blocks & assertions and use it on the server side too (For Node / Express projects)

 

Glad you like it. I hated it when we first used it in work about 10 months ago, it did lots of horrible things like autoMocking modules, but that's been taken out and lots of good work has been done on it. We decided to try it again in work and will be sticking with it for the foreseeable future now.

 

It was initially aimed at React consumers but it's useful outside of that. We wrap out Nightmare.js E2E tests in Jest blocks & assertions and use it on the server side too (For Node / Express projects)

 

The documentation is easy to follow, which helps.

 

Also, I've been finding the test-first approach OK so far. Writing the test before the implementation means I'm writing less code and it's so much nicer to read. Although, I'm not sure if this is more related to functional programming as I've recently been learning a lot about it and have been trying to implement the methodologies as much as possible.

 

JavaScript is so awesome right now, though!

 

Looks cool that, thanks for sharing!

 

Have you tried wallaby btw? I love it.

 

Nah, I don't write enough tests in my day-to-day job to warrant it. I was watching the Jest talk at React Conf a couple days ago, both watch mode and snapshots look really cool. Watch mode seems a lot like Wallaby in how it works.

Horses for courses and all that I think. I don't think there's any real advantage to using Jest from what I can see. It seems to work well enough, but Mocha/Chai works perfectly well for me and having played with Jest a little bit now I just saw no reason at all to change.

 

 

This is the video I watched. I like the idea of using a single framework to handle everything from standard assertions to UI. I'd be interested to find out if you consider anything on the video to be bad practice, or perhaps there's another way the example could be tested.

 

---

 

On a side note, the videos from React Conf are up. Some of the highlights for me were Tom Occhino - React Fiber, Robert Zhu - Realtime React Apps with GraphQL, Michael Jackson & Ryan Florence - Learn Once, Route Anywhere and Guillermo Rauch - Next.js.

The main plus for Jest is that it requires no setup, it just works out of the box. I know you don't see a huge benefit in coverage reporting, but with Jest it's literally just an option that you pass into the the call. There's no messing around setting up Istanbul etc. For those times that you do need to Mock you don't have to pull in Sinon or some other library, again it's all just baked into Jest and the documentation is very well thought out.

While I don't think you'd gain much yourself by switching to Jest, for those just starting out it's a nice place to start without having to worry about confusing setup and config.

 

Snapshots are just useful to see if you have made breaking changes to a presentational component (UI), on paper that seems useful but to be honest we're not using them and aren't really missing the feature. It's quite immature and I've heard reports of some bugs coming out. I think it's something worth keeping our eyes on as things progress.

 

Correct me if I am wrong but shallow rendering is going to allow your tests to run faster and means that your test is only concerned with that one component whereas Mount feels more like an integration test. as it renders that component and all of it's descendants

We're calling them (mount rendered tests) Duck tests in our project at work as it kind of mirrors the Redux Ducks structure so we will test a Duck.

 

https://github.com/erikras/ducks-modular-redux for those interested / curious to know what a Redux Duck is

 

We have found both shallow and mount tests to be both useful, I think it's down to testing the right things, we tend to test the logic in a component and not bother testing that a static header is present in the JSX for example. That's where snapshots would come in.

 

We could have a component <Users /> which renders a list of users ordered by surname.

import React, { PropTypes as T } from 'react'
import sortBy from 'utils/sortby'
import User from './User'

const Users = ({ users = [] }) => {
  const sortedUsers = sortBy(users, 'surname')
  return (
    <div className="c-users-card">
      <h2 className="c-title">Users list</h2>
      <p>Some description of our users</p>
      <ul className="c-users-list">
        {sortedUsers.map(u => <User key={u.id} user={u} />}
      </ul>
    </div>
  )
}

Users.propTypes = {
  users: T.arrayOf(T.shape({})
}

export default Users

We would write a test to ensure that the component renders the correct number of User components and sorts them by their last name. For this test Enzyme's Shallow rendering utility is sufficient.

import React from 'react'
import { shallow } from 'enzyme'

import Users from '../Users' 
import User from '../User'

const users = [
  {
    id: 'user-1',
    firstName: 'John',
    surName: 'Smith',
    age: 25,
  }, {
    id: 'user-2',
    firstName: 'Fred',
    surName: 'Flintstone',
    age: 98,
  }, {
    id: 'user-3',
    firstName: 'Jack',
    surName: 'Sparrow',
    age: 40,
  }
]

describe('<Users />', () => {
  it('renders a list of users ordered by surname', () => {
    const $ = shallow(<Users {...{ users }} />
    const findUserIdByIndex = index => $.find(Users).at(index).prop('key')

    expect($.find(Users).length).toBe(3)
    expect(findUserIdByIndex(0)).toEqual('user-2')
    expect(findUserIdByIndex(1)).toEqual('user-1')
    expect(findUserIdByIndex(2)).toEqual('user-3')
  })
}) 

So we are just testing the logic of the component, we don't test that the heading and paragraph component are visible or the classnames. We would test classnames that are dependant on logic of course. Snapshots would come in to ensure that any changes to this component get flagged up. Again I'm not sure how useful that actually is?

 

The sortBy utility would be independently tested itself.

Edited March 17, 20179 yr by rbrtsmith

Interesting article on functional setState

Edited March 20, 20179 yr by Jack

Interesting article on functional setState

 

It should always have been functional rather than being able to accept an object or a function, passing an object like the article describes can be error prone. That said I'm using Redux for all the apps I am building right now so don't have much use for setState.

It also has the added bonus that I can avoid using classes for my components as long as they don't have lifecycles events.

 

Once you're familiar with Redux it doesn't add much complexity or boilerplate to your app, so I use it even for small ones unless it is really trivial. It also ties nicely into routing etc. And as your app grows which it almost always does you don't have to mess around refactoring components having to move state higher up the tree and then having to pass lots of props down to components that only their descendants care about. Redux actually avoids a lot of boilerplate and components only receive the props they actually care about.

Edited March 20, 20179 yr by rbrtsmith

Just a quick one. if you go to next.frontendmasters.com you can use the new video player. It's much better, especially how it tracks your completed steps.

An interesting repo here covering a full stack development app in Javascript: Backend, frontend, infrastructure & deployment. It gives a good overview of the whole stack.

While doesn't go into great deal into any of the concepts I think it's a solid introduction to the most modern tools used in JS application development.

https://github.com/verekia/js-stack-from-scratch

 

Only part that seems to be missing is a database layer, but it looks as though the Author is planning to add this soon.

Edited March 24, 20179 yr by rbrtsmith

I spent a couple hours today adding acceptance tests to a site using CodeceptJS and PhantomJS. It works really well.

 

My question is, how far do you go with this kind of test? At the moment I'm literally just testing a couple payment forms across the site, which what I intended to do, but it looks like you could go nuts with tools like this, and have tests for everything. Is there some general rule for what these tests should cover, other than essential pieces of UI?

I spent a couple hours today adding acceptance tests to a site using CodeceptJS and PhantomJS. It works really well.

 

My question is, how far do you go with this kind of test? At the moment I'm literally just testing a couple payment forms across the site, which what I intended to do, but it looks like you could go nuts with tools like this, and have tests for everything. Is there some general rule for what these tests should cover, other than essential pieces of UI?

 

These are more End to End (E2E) tests, rather than unit tests so you shouldn't have so many of these, just test a few critical paths. They run very slowly compared to unit level tests. Paul can explain more.

 

But the project I am working on at the moment, there are 4 E2E tests, about 12 integration tests (Enzyme mount) and close to 500 unit tests. My example a few posts back is a unit test.

 

With my unit tests I test functionality, logic, branching and so on. I don't things like if my template renders a static <h1> heading. If it rendered it conditionally then I would test that. If it maps of a number of users and renders a <User /> component for each I will test that and may test that it passes in the correct props.

 

By the way I have read in a few places that PhantomJS is not really maintained much anymore? maybe somebody else can shed some light on that? We have used Night-watch and recently switched to Nightmare for end to end tests. Nightmare in comparison to some others really requires minimal setup.

Edited April 2, 20179 yr by rbrtsmith

 

These are more End to End (E2E) tests, rather than unit tests so you shouldn't have so many of these, just test a few critical paths. They run very slowly compared to unit level tests. Paul can explain more.

 

But the project I am working on at the moment, there are 4 E2E tests, about 12 integration tests (Enzyme mount) and close to 500 unit tests. My example a few posts back is a unit test.

 

With my unit tests I test functionality, logic, branching and so on. I don't things like if my template renders a static <h1> heading. If it rendered it conditionally then I would test that. If it maps of a number of users and renders a <User /> component for each I will test that and may test that it passes in the correct props.

 

By the way I have read in a few places that PhantomJS is not really maintained much anymore? maybe somebody else can shed some light on that? We have used Night-watch and recently switched to Nightmare for end to end tests. Nightmare in comparison to some others really requires minimal setup.

 

It's easy to swap the driver out for NightmareJS. To be honest, I thought Nightmare was older, I've never heard of it before so I used Phantom instead.

 

That's an interesting ratio in terms of e2e tests and unit, and yeah they are slow to return the results back. I only added Codecept originally because I'm building a site that uses a couple of multi-step forms, and testing manually is a total pain. I've already caught one issue with the client-side validation which triggered the test to fail, so it has been useful so far. I like the idea of screenshots being returned as well.

 

I'm still not 100% sure what integration tests are for yet, but there's a testing course coming up on FEM so hopefully I'll be able to see how everything fits together.

On the frontend an integration test might be testing a component that is wrapped in Redux's <Connect /> component, like a register users page for example. Your test will import the component and pass it the store with <Provider>, some stubbed state and you will test things like submissions - what happens with error handling, and so on. Does the store get updated with the right state? You will use Enzymes mount() function which renders the full tree for that component and it's descendants.

Essentially here you are testing the integration of Redux with the rest of your application.

 

For unit tests you will either test the utility functions individually or if it's a React component use Enzymes shallow() function which does not render the descendant tree, so you test that component or function in isolation. These tests run extremely fast, there are no API calls made.

Again @@citypaul can probably expand on this. I've only been testing properly for around a year and I've still much to learn!

An example of an integration test:

import { mount } from 'enzyme'
import React from 'react'
import { Provider } from 'react-redux'

import createStore from 'store'
import { UPDATE_CYCLES } from 'constants/permissions'
import Form from 'modules/CyclesDetail/Form'

global.window.matchMedia = () => true

describe('Cycles Detail Form', () => {
  let store
  let wrapper

  beforeEach(() => {
    const user = {
      role: {
        permissions: [{ id: UPDATE_CYCLES }],
      },
    }
    const data = {
      cycles: {
        'cycle-1': {
          type: 'cycles',
          id: 'cycle-1',
          title: 'First Cycle',
          startDate: '2017-02-01',
          endDate: '2017-02-21',
        },
      },
    }
    store = createStore({ api: { data } })
    wrapper = mount(
      <Provider store={store}>
        <Form user={user} />
      </Provider>,
    )
  })

  it('should show title of the previous cycle', () => {
    expect(wrapper.text()).toMatch('PreviousFirst Cycle')
  })

  it('should prevent submission and show validation errors', () => {
    const submit = wrapper.find('form').props().onSubmit
    const findErrors = () => wrapper.find('.c-field-info--error')

    expect(findErrors().length).toBe(0)
    submit()

    const errors = findErrors()
    expect(errors.at(0).text()).toEqual('Title is required.')
    expect(errors.at(1).text()).toEqual('End Date is required.')
  })
})

IIRC you should write unit tests before your implementation - just the tests for that function not the entire application!

Edited April 3, 20179 yr by rbrtsmith

Been working a lot with Will around testing and Redux and what he's promoting is pretty much the same as the redux docs, we test the reducers in isolation because they have flow control and are their own self contained function e.g.

const addTodoReducer = (state, action) => {
  switch (action.type) {
    case 'ADD_TODO':
      return {
        ...state,
        [action.payload.id]: {
           id: action.payload.id,
           text: action.payload.text,
           isComplete: false,
           urgency: action.payload.urgency
        }
      }
    default:
      return state
  }
}

You'd surely want to test the above reducer..?

describe('addTodoReducer', () => {
  it('adds a new todo to the state when the action type equals "ADD_TODO"', () => {
    const action = {
       type: 'ADD_TODO',
       payload: {
         id: 'test-id',
         text: 'test-text',
         urgency: 'test-urgency'
       }
    }
    const state = { abc: {} }
    const expected = {
      abc: {},
      'test-id': {
        id: 'test-id',
        text: 'test-text',
        urgency: 'test-urgency',
      }
    }

    expect(addTodoReducer(state, action).toEqual(expected)
  })
  
  it('returns the state when the action type does not equal "ADD_TODO"',() => {
    const action = { type: 'TEST' }
    const state = { abc: {} }

    expect(addTodoReducer(state, action).toEqual(state)
  })
})

This of course is a very simple reducer, in applications such as the ones we are working on things get far more complex, especially when dealing with actions that handle async code and requests to the server, we typically handle those via Redux middleware so that it can handle actions that are functions or promises instead of plain objects.
I feel that due to their complexity they should be tested.
We often have functions like mapStateToProps that itself calls a lot of internal functions to the module that do things such as data transformation from the store from JSON API to a normalised structure, selecting bits of state to pass in etc. We don't test those functions internally (generally) but test the mapStateToProps function directly - i.e. testing the API and not the internal implementation details.
It's a bit fuzzy I feel where you draw the lines here. Not so black and white like you say which leads to confusion in the industry.

Edited April 3, 20179 yr by rbrtsmith

I thought I read here somewhere in one of your discussions that you were saying that you shouldn't use IDs in selectors. However, while I can think that,mostly, you could just use class all time and never ID,

 

I can think of one case where an id selector would be ok: internal anchor tags.

For instance, this is acceptable:

<a href="#stuff"> Bla bla bla </a>

.....

<h1 id="stuff"> Bla bla bla </h1>

But this will cause problems:

<a href=".stuff"> Bla bla bla </a>

.....

<h1 class="stuff"> Bla bla bla </h1>

And this doesn't work properly with the internal anchor either:

<a href="#stuff"> Bla bla bla </a>

......

<h1 class ="stuff"> Bla bla bla </h1>

An internal anchor tag should only be going to one place, hence using an id selector should be fine.

Granted, you could use a class selector just with that anchor element only, but it's overkill.

Edited April 8, 20179 yr by MongooseLover

 

I thought I read here somewhere in one of your discussions that you were saying that you shouldn't use IDs in selectors. However, while I can think that,mostly, you could just use class all time and never ID,

 

I can think of one case where an id selector would be ok: internal anchor tags.

For instance, this is acceptable:

<a href="#stuff"> Bla bla bla </a>

.....

<h1 id="stuff"> Bla bla bla </h1>

But this will cause problems:

<a href=".stuff"> Bla bla bla </a>

.....

<h1 class="stuff"> Bla bla bla </h1>

And this doesn't work properly with the internal anchor either:

<a href="#stuff"> Bla bla bla </a>

......

<h1 class ="stuff"> Bla bla bla </h1>

An internal anchor tag should only be going to one place, hence using an id selector should be fine.

Granted, you could use a class selector just with that anchor element only, but it's overkill.

 

 

The issue with ID's is when you use them with CSS not HTML. As soon as you throw ID's in CSS, you stop that piece of CSS from being re-usable. They also raise the specificity of your CSS, here's an example of that https://jsfiddle.net/05ee4xsh/, notice how the classes can't override the ID because it has a higher level of specificity. This causes big problems in any codebase, it will make code brittle and refactoring a nightmare, most will try and "temporarily" patch the issue using !important but I highly recommend not going down that path.

 

The issue with ID's is when you use them with CSS not HTML. As soon as you throw ID's in CSS, you stop that piece of CSS from being re-usable. They also raise the specificity of your CSS, here's an example of that https://jsfiddle.net/05ee4xsh/, notice how the classes can't override the ID because it has a higher level of specificity. This causes big problems in any codebase, it will make code brittle and refactoring a nightmare, most will try and "temporarily" patch the issue using !important but I highly recommend not going down that path.

 

It's also about following the Single Responsibility Principal. That hash / ID should only have one concern, if you then attach styling to it as well it has multiple concerns which can lead to bugs, especially within teams. If we no longer have regions then a developer might want to remove the IDs to clean up the code, not realising that it is also being used as a style hook.

 

And what Jack says about IDs in general is 100% correct. Use classes as styling hooks, use element selectors for global base styling. and don't qualify selectors e.g.

 

h1 .foo {} // Bad!

.foo {} // fine!

Although this thread is JavaScript so we should really just keep on topic with that, a CSS thread can be created if we want to discuss CSS selectors

Edited April 10, 20179 yr by rbrtsmith

It's official. PhantomJS maintainer stepping down

Chrome is adding a new headless mode, FireFox is also doing the same. It's going to be a big step forward compared to the current tools on offer.

Thankfully not had to mess around with PhantomJS as we've been using Nightmare which uses Electron https://electron.atom.io/ This is what the Atom text editor is built in as well as Slack amongst others.

https://github.com/segmentio/nightmare

Nightmare:

Under the covers it uses Electron, which is similar to PhantomJS but roughly 2 times faster and more modern.

 

Still not sure how significant this news is as Electron uses Chrome under the hood… Still a step in the right direction I guess.

Edited April 13, 20179 yr by rbrtsmith

Also React recently released a fairly significant update https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html#migrating-from-react.proptypes

 

The long and short is that things like PropTypes are being moved out into their own package to reduce bundle size for those not using proptypes. Those who want them but still want to keep bundle sizes down I would recommend looking at FlowType which brings static type checking to JavaScript and can be used in place of PropTypes for props...

Edited April 13, 20179 yr by rbrtsmith

Thankfully not had to mess around with PhantomJS as we've been using Nightmare which uses Electron https://electron.atom.io/ This is what the Atom text editor is built in.

 

Still not sure how significant this news is as Electron uses Chrome under the hood… Still a step in the right direction I guess.

 

I didn't find Phantom bad to work with. The maintainer has essentially managed to build and maintain a headless browser that works cross-platform. It's a huge amount of work for one person, so I can understand letting the Chrome team deal with it.

 

Electron apps tend to be quite large because they ship with Chromium as well as the Electron framework each time, even if you only need a subset of features. I guess the benefits are that you can test your app against new browser features and it should be faster to integrate testing frameworks into your current workflow.

 

I need to give NightmareJS a shot, even though the Chrome option seems the best longterm. Do you just install via npm, or do you need to download a separate electron app?

Just download Nightmare from NPM and it will just work, the size of electron doesn't matter, it's not like that code / dependency ships with the application. It requires far less boilerplate in your code than phantom and you don't have to go through the process of setting up Selenium. It just works out of the box.

 

Like Paul said, I wouldn't focus too much on these end to end tests, there should only be a few to test that the app and API integrate together, almost all your tests should be at a unit level.

Edited April 13, 20179 yr by rbrtsmith

Just download Nightmare from NPM and it will just work, the size of electron doesn't matter, it's not like that code / dependency ships with the application. It requires far less boilerplate in your code than phantom and you don't have to go through the process of setting up Selenium. It just works out of the box.

 

Like Paul said, I wouldn't focus too much on these end to end tests, there should only be a few to test that the app and API integrate together, almost all your tests should be at a unit level.

 

Without a doubt. It's good to know what's around though.

A couple useful links:

 

https://yarnpkg.com/en/docs/migrating-from-npm#toc-cli-commands-comparison - I couldn't work out why --save-dev wasn't working with Yarn, this article lists the command differences with Yarn & NPM.

 

http://passportjs.org - A decent looking auth module for Node that supports just about everything.

 

 

A couple useful links:

 

https://yarnpkg.com/en/docs/migrating-from-npm#toc-cli-commands-comparison - I couldn't work out why --save-dev wasn't working with Yarn, this article lists the command differences with Yarn & NPM.

 

http://passportjs.org - A decent looking auth module for Node that supports just about everything.

 

 

You probably already know now but with yarn it automatically saves to dependencies when you run

yarn add <packageName>

if you want to add it to your dev dependencies it's

 

yarn add -D <packageName>

I use Yarn exclusively now at home and in work. The lockfile it generates is essentially the same as an NPM shrinkwrap file but it does this by default meaning sharing your project across developers and environments becomes less troublesome as all dependencies and sub-dependencies are locked down.

 

As an aside I am currently learning Docker https://www.docker.com/what-docker which essentially allows you to put your app or services into containers that are completely independent from the host OS and from each other. The build for these containers can be configured in a Dockerfile which again makes collaboration for projects on different machines more consistent and in turn also gives confidence that your local dev environment matches the environment you plan to deploy to. It seems like a seriously good tool so far.

Edited May 3, 20179 yr by rbrtsmith

I worked it out eventually, but I had to look up how to save dev dependancies. I really like Yarn so far, the speed is great.

 

I've only looked into Docker briefly, mainly because it would be awesome to have a dev container that mirrored our live setup. Am I right in thinking you can have a file sort of like package.json that will tell Docker to build a specific environment? I think it's called a compose file or something, but that would be incredible for on-boarding new developers.

I worked it out eventually, but I had to look up how to save dev dependancies. I really like Yarn so far, the speed is great.

 

I've only looked into Docker briefly, mainly because it would be awesome to have a dev container that mirrored our live setup. Am I right in thinking you can have a file sort of like package.json that will tell Docker to build a specific environment? I think it's called a compose file or something, but that would be incredible for on-boarding new developers.

Yarn is super speedy, IIRC it caches packages on your host machine

 

I'm pretty new to Docker myself. So I may have to be corrected here but my understanding is

 

A Dockerfile is like a blueprint to generate a Docker image. and then to spin up a container that consumes that image you can either run a command that maps the ports, a volume between your host machine and the container OR use Docker compose to save this as code.

I think where Docker compose becomes most useful is if you have a number of containers each containing a service and you can spin them all up at once via a single command - a docker-compose.yml file contains the config for this.

http://start.jcolemorrison.com/authorized-resources-and-database-migrations-with-strongloops-loopback/ seems like a good tutorial that includes a lot of Docker stuff that might help

Edited May 3, 20179 yr by rbrtsmith

Another interesting project from the FB team https://prepack.io/

 

There's a webpack plugin for it, but I think it's still early days so I wouldn't recommending using it in production.

Another interesting project from the FB team https://prepack.io/

 

There's a webpack plugin for it, but I think it's still early days so I wouldn't recommending using it in production.

 

The risk I see in a tool like this, which isn't transpiling or minifying your code, it's changing what your code actually does. It might work well on pure functions but how is it going to handle functions with side effects? The exploration is great, but I'd be very wary about using it in production.

Edited May 5, 20179 yr by rbrtsmith

 

The risk I see in a tool like this, which isn't transpiling or minifying your code, it's changing what your code actually does. It might work well on pure functions but how is it going to handle functions with side effects? The exploration is great, but I'd be very wary about using it in production.

 

Agreed, and they don't recommend using it in production, I think it's years off being stable. However, this is essentially what engines like V8 do already. The difference is they have abstracted the same rules into the build process, so that the browser won't have to perform the same time-consuming operations at run time.

 

These are the kind of things we will start seeing in the future. The Ember team have a similar method of converting JS to bytecode in Glimmer, React Fiber will schedule your functions for you, Webpack can perform tree shaking, generally tools are going to have to change code somewhere to get the performance benefits people want.

Edited May 9, 20179 yr by Jack

Also, and without meaning to sound like a broken record, if you have great automated tests, you could test the output of the overall build process and continue working with confidence that way.

 

Paul, please correct me if I am wrong but aren't the only tests that run on the compiled output the E2E tests? at least that is the case on projects I am working on... and we only have a few of those so they don't test every possible user story.

Also, and without meaning to sound like a broken record, if you have great automated tests, you could test the output of the overall build process and continue working with confidence that way.

 

That's a good point. I've actually had quite a few bugs caused from a build output in the past, even one where Babel wasn't compiling properly (which was my fault, not Babels). Do you tend to run your tests against your production build as well as dev?

Adding to the general discussion here on testing a module me and a colleague have been working on has been open sourced, it's essentially a visual timeline for events using React you essentially import the component and pass it the relevant props to render out a timeline.

I think this module is a good example of how you would unit test react components (There are no end to end tests as this is literally a component to be dropped into a project). Each relevant directory has a __tests__ directory that test all the files in there. It's got 100% coverage and I believe tests all the possibilities here. https://github.com/JSainsburyPLC/react-timelines.

We use Jest and Enzyme for testing our React components. An example of a test: https://github.com/JSainsburyPLC/react-timelines/blob/master/src/__tests__/index.jsx

https://learnnode.com released by Wes Bos today, and currently on sale (you can also use the code WESBOS to get $10 off).

 

I had to grab this, I've wanted to build a full app with Node for ages. I've got other courses to finish first, but it's at a good price at the moment.