Unit testable components pt.1: Overview

Bad tests are worse than no tests

This code should be changed or refactored, but that would mean I have to update my tests...

Testing UI behavior is really hard, and you can get lulled into writing sloppy tests. Sloppy tests are unmaintainable and encourage "behavior locking". It's a problem that only grows as time goes on.

Testing React components is hard

Frontend testing requires, in one form or another, a mocked DOM, which is a beast in its own rite. Your tests can't be run like a basic function, because the true environment is the browser. Which is what enzyme was created for. It's a mandatory supplement to jest for component testing.

Component design matters a lot more than you think

Well designed components are easy to test

Spaghetti is easy to right, but hard to test and maintain. Large components also hurt performance, for reasons that can be dove into on another day. Here are the qualities that I value when I design components.

  • Small components that represent a singular idea
  • Few or no props passed in from parent (flux implementation needed)
  • Minimal business logic

When you do things the right way, everything just "falls right into place"

These principles that I value make code clean, maintainable, and implies separation of concerns (which vanilla React does a bad job of). Deep dependencies between UI elements and their resulting behavior inside a component is the pain point when it comes to testing. It is advantageous to minimize it.

Redux gives us an ecosystem to create separation of concerns

Redux is its own data flow ecosystem. Its algorithmic operations have nothing to do with the DOM. The only job of flux is to feed data to components, making it the perfect place to abstract out complex behavior.

Testing advantages of abstracting out business logic

  • Very few mocked functions (one or two, at most)
  • No spies
  • No value assertions of actions or api calls (except for local state and render logic)
  • Only render logic needs to be asserted

Starting to sound pretty nice, right? Well, sit tight. I'll get to it in pt.2

Comments

Post a Comment

Popular posts from this blog

Contrasting var and ES6s new declarations: let and const

let and const are two new declaration types in JavaScript, which have the ability to completely replace var declaration. To use them effectively, and understand why they can be a direct replacement, it's important to understand how they work. var is function scoped. It is hoisted and initialized at the top var , regardless of where it is assigned, will become declared and initialized at the beginning of the function. This means that any variable you declare will be available everywhere inside the function. This process is referred to as hoisting. Hoisted variables with var are declared and initialized at the top of the function, but have no value All variables that are declared and initialized with var are initialized as undefined . They have no value until you reach the line of code that assigns it a value. const undefinedConsoleLog = _ => { console.log(sadlyUndefined) //undefined var sadlyUndefined = 'declared by var, und
Read more

Modularity vs. Abstraction. Which is More Important?

Coupling? Bad. Coupling is the enemy of modularity. Coupling creates the need to understand the inner workings (implementation details) of multiple functions/objects/entities in order to understand what the code is doing. Abstractions? Good. Abstractions are a natural concept in this world. I do not need to understand how a car works in order to drive mine. In programming, being able to use functions and components without understanding their inner workings is a sign of well-designed abstraction. A clear and tight interface that is easy to work with is a sign of good code. Good modularity with bad abstractions? Could be better. It's not fun to read, but at least you know where everything is. This tends to create large components and classes, but I see it as the lesser of two possible evils. Bad modularity with good abstractions? The worst spaghetti possibl
Read more

Unit testable components pt.3: Testing components

My approach to component testing There are multiple resources that show how to test components. When you read between the lines, they are actually describing their philosophy on how a component should be tested. My tests are basic and practical because my components are dumb My components have the following properties No api calls Small encapsulated components Minimal Redux actions As a consequence, my tests have the following principles Shallow mount component directly. Ignore Redux's connect higher order function (HOF) in test
Read more