Common Testing Mistakes

TODAY IS THE DAY AND I AM REALLY EXCITED CAN YOU TELL!?

Tell your boss, tell your co-workers, tell your dog 🐶. Today’s the day you can snag TestingJavaScript.com for the early bird price! WATCH IT TODAY!!!

Today let’s talk about some common mistakes that people make when testing JavaScript.

Mistake Number 0

One of the biggest mistakes you could make would be missing out on my full Testing JS course. (see what I did there?)

Mistake Number 1

Testing implementation details. I harp on this a lot but it’s because it’s a huge problem in testing and leads to tests that don’t give nearly as much confidence as they could. Here’s a very simple example of a test that’s testing implementation details:

// counter.js
import React from 'react'

export class Counter extends React.Component {
  state = {count: 0}
  increment = () => this.setState(({count}) => ({count: count + 1}))
  render() {
    const {count} = this.state
    return <button onClick={this.increment}>{count}</button>
  } 
}

// __tests__/counter.js
import React from 'react'
// (it's hard to test implementation details with react-testing-library,
//  so we'll use enzyme in this example 😅)
import {mount} from 'enzyme'
import {Counter} from '../counter'

test('the increment method increments count', () => {
  const wrapper = mount(<Counter />)
  // don't ever do this:
  expect(wrapper.instance().state).toBe(0)
  wrapper.instance().increment()
  expect(wrapper.instance().state).toBe(1)
})

So why is this testing implementation details? Why is it so bad to test implementation details? Here are two truths about tests that focus on implementation details like the test above:

1. I can break the code and not the test (eg: I could make a typo in my button’s onClick assignment)
2. I can refactor the code and break the test (eg: I could rename increment to updateCount)

These kinds of tests are the worst to maintain because you’re constantly updating them (due to point #2), and they don’t even give you solid confidence (due to point #1).

In my course I’ll show you the right way to write tests and avoid this common mistake.

Mistake Number 2

Trying to go for 100% code coverage for an application is a total mistake and I see this all the time. Interestingly I’ve normally seen this as a mandate from management, but wherever it’s coming from it’s coming out of a misunderstanding of what a code coverage report can and cannot tell you about the confidence you can have in your codebase.

What code coverage is telling you:

• This code was run when your tests were run.

What code coverage is NOT telling you:

• This code will work according to the business requirements.
• This code works with all the other code in the application.
• The application cannot get into a bad state

Another problem with code coverage reports is that every line of covered code adds just as much to the overall coverage report as any other line. What this means is that you can increase your code coverage just as much by adding tests to your “About us” page as you can by adding tests to your “Checkout” page. One of those things is more important than the other, and code coverage can’t give you any insight into that for your codebase…

There’s no one-size-fits-all solution for a good code coverage number to shoot for. Every application’s needs are different. I concern myself less with the code coverage number and more with how confident I am that the important parts of my application are covered. I use the code coverage report to help me after I’ve already identified which parts of my application code are critical. It helps me to know if I’m missing some edge cases the code is covering but my tests are not.

I should note that for open source modules, going for 100% code coverage is totally appropriate because they’re generally a lot easier to keep at 100% (because they’re smaller and more isolated) and they’re really important code due to the fact that they’re shared in multiple projects.

I talked a bit about this in my livestream the other day, check it out!

Conclusion

I hope this is helpful! If you want to be confident in shipping your application to production, you need to watch my course! Today’s the day! TestingJavaScript is now available at the limited time Early Bird price.

Buy it now for $162. (A savings of 40%)

Let’s put that into perspective. This is a great value for you, because typically a training of this magnitude would require plane tickets, an event ticket, a hotel room, a rental car, and spending money for overpriced & underwhelming food.

Needless to say, that would cost a whole lot more money than $162, not to mention the time factor.

Speaking of time, this course is HUGE. Like over 100 dense videos huge. Like ~5 dense hours of testing huge.

Don’t miss out on this Early Bird special!

=> Build your testing skill now!

-Kent

P.S. Enjoy your testing weekend!