DEV Community: Gavin Macken

Developing a Client-Side Testing Strategy

Gavin Macken — Fri, 01 Oct 2021 03:05:18 +0000

Why Test?

Testing improves the quality of your product and makes it easier to successfully scale your application by allowing for more developers to reliably make updates and push with confidence.

You know the drill: A user reports a bug, they get frustrated, perhaps they can’t use your application at all.

The bug is reported to the team, and because of its severity, it’s full steam ahead trying to resolve the problem. The sprint grinds to a standstill as your resources are sucked up and user trust erodes.

This makes things very stressful indeed for your committed dev team that has the responsibility to resolve it and not push up fragile code in the first place.

There seems to be no easy way of handling this situation. That’s why the best thing to do is avoid it by wrapping your code in tests that must pass before deployment, capturing these bugs before they wiggle up to the surface and see the light of day.

They allow us to find more bugs more easily when they do occur and eliminate worries when re-factoring, eventually leading to better code.

Release with confidence — particularly when deploying native applications, as these have a longer release process. When a bug is released, it's a lot of effort to fix.

The rationale for testing is solid. If you want to improve the quality of your product and need to scale, testing is required.

The Challenge

But testing is one of the more challenging tasks in front-end development.
First of all, testing is expensive, time and effort are required, and the increase in product quality can be difficult to measure at first.

Some well-thought-out manual tests could be performed and are quick to create. However, the effort needed compounds every time you release. While automated tests can take longer at first, they save time later. With that said, they still require maintenance.

We rely on developers to make a calculation, balancing the Effort V Impact equation: how much effort is required and the impact that effort has on a product.

Testing Best Practices

OK, so that's all some pretty high-level stuff. Although there is no definitive solution for your unique application, there are well-thought-out and popular testing philosophies and best practices that can help, and it’ll likely be a unique blend that suits your team’s needs.

The best explanation I’ve heard for testing came from Kent C. Dodds’ podcast, where a metaphor was used to describe testing to be like painting a wall.

If you have a wall with corners, obstacles, windows, and perhaps a door, just throwing a bucket of paint at the wall won’t suffice. You’ll waste a lot of paint on areas that didn’t need it and miss all around the corners and the door.

Instead, we need different brushes to do a good job on our wall. We need a roller to do the heavy work and achieve a lot of coverage, a large brush for the corners, and maybe a fine detailed brush for the areas around your window being careful not to splash paint on your mahogany window sills.

Cool, now let’s pick up our developer brushes.

I’m sure you’ve come across this famous triangle: the Testing Pyramid. These four layers are the front-end bible to shipping code with speed and confidence.

So what are we dealing with here?

Static types — A static type system and a linter can be used to capture basic errors like typos and syntax (think TypeScript).
Unit tests — These target the critical behavior and functionality of your application. Unit tests test the smallest unit of functionality (typically a method/function).
Integration tests — They make sure everything works together correctly in harmony. Stack Overflow user Mark Simpson wrote, “Integration tests build on unit tests by combining the units of code and testing that the resulting combination functions correctly.”
UI tests — Also called functional tests or end-to-end testing. This is click testing of critical paths in your application within a browser or device. It can be both manual or automatic.

Getting the Balance

You inevitably put most of your attention toward the base of the pyramid — the unit tests. These are the easiest tests to write.
We could create a lot of these quickly, but you could find yourself asking, “What is the advantage of these tests I wrote?”

These unit tests we created are great, as they improve our test coverage. But how much do you feel they improve your confidence that the app will perform in a real-world setting?
Here’s another great reference from Kent C. Dodds, who is essentially the JavaScript testing guru. This one particular line has stuck with me:

“The more your tests resemble the way the software is used, the more confidence they can give you.”
And that there is the challenge — the Effort V Impact trade-off.
Unit tests are great in that they can be done with minimal effort. They’re isolated tests, so they don't have the same upkeep that integrated testing or end-to-end requires. It's for that same reason that they can’t give you the confidence that end-to-end or integration tests provide.

Let's go back to that important question again: “What is the advantage of these tests I wrote?”

Kent Beck is the person credited with having rediscovered test-driven development.
“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence … If I don’t typically make a kind of mistake, I don’t test for it.*” — Kent Beck on Stack Overflow

I believe testing to perfection is a flawed approach. Rather, testing to confidence is a better way to indicate that you're doing enough tests.

Defining what confidence looks like will be entirely up to you and your team. For my team and our current size and situation, I promote that if something is very unlikely to fail, then I'm very unlikely to test for it.

Composition > Inheritance in 4 mins

Gavin Macken — Mon, 27 Sep 2021 19:39:49 +0000

JavaScript polymorphic behavior with ES6

Composition over inheritance is the principle that classes should achieve polymorphic behavior and code reuse by their composition rather than inheritance from a base.

Inheritance

To better understand why we might favor composition over inheritance let’s first look at inheritance in Javascript, specifically ES6. The extends keyword is used in class declarations or class expressions to create a class that is a child of another class.

class Plant{
 constructor(name){
  this.name = name
 }

 water(){
    console.log("Water the " + this.name)
 }

 repot(){
    console.log( "Repot the " + this.name)
 }
harvest(){
    console.log("Harvest the " + this.name)
  }
}

class Vegetable extends Plant {
  constructor(name, size, health){
   super(name)
   this.health = health;
  }
}

class Flower extends Plant {
  constructor(name, size, health){
   super(name)   
   this.health = health;
  }
}

class Fruit extends Plant {
  constructor(name, size, health){
   super(name)
   this.health = health;
  }
}

We see a potential problem beginning to form using the inheritance pattern.

The water method is shared among the instances of Flower, Vegetable and Fruit which is helpful since they will all need to be watered, but there is no need for an instance of Flower to have access to the harvest method and my vegetables are planted in the ground so there is no reason for them to have access to the repot method.

The associations should look like this:

Fruits are watered, repotted, harvested
Flowers are watered repotted
Vegetables are watered, harvested

OK, so what if I do something like this

class Plant{
  constructor(name){
   this.name = name
  }

 water(){
    console.log("Water the " + this.name)
 } 
}

class Vegetable extends Plant {
  constructor(name, size, health){
   super(name)
   this.health = health;
  }
  harvest(){
    console.log("Harvest the " + this.name)
  }
}

class Flower extends Plant {
  constructor(name, size, health){
   super(name)   
   this.health = health;
  }
  repot(){
    console.log( "Repot the " + this.name)
  }
}

class Fruit extends Plant {
  constructor(name, size, health){
   super(name)
   this.health = health;
  }

  repot(){
    console.log( "Repot the " + this.name)
  }
  harvest(){
    console.log("Harvest the " + this.name)
  }
}

This is a little better, but now we end up creating duplicate methods on the different instances that are doing the same thing, not adhering to DRY principles. This is a problem that can be created by the inheritance pattern.

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. — Joe Armstrong. Creator of Erlang.

Inheritance is by its nature tightly coupled compared to composition. An inheritance pattern forces us to predict the future and build a taxonomy of types. So unless we can predict the future we are invariably going to get a few things wrong.

Composition

A compositional pattern can help us here.

const harvest = () => {
  console.log("Harvesting")
}
const water = () => {
  console.log("Watering")
}
const repot = () => {
  console.log( "Repotting")
}
const Flower = (name) => {
 return Object.assign(
  {name},
  water(),
  repot()
  )
}
const Vegatable = (name) => {
 return Object.assign(
  {name},
  water(),
  harvest()
  )
}
const Fruit = (name) => {
 return Object.assign(
  {name},
  water(),
  repot(),
  harvest()
  )
}
const daffodil = Plant();
daffodil.harvest() // undefined
const banana = Fruit();
banana.harvest() // Harvesting

By favoring composition over inheritance and thinking in terms of what things do rather than what things are, you can see that we have freed ourselves from the tightly coupled inheritance structure.

We no longer need to predict the future because additional methods can be easily added and incorporated into separate classes.

One thing you may notice is that we no longer rely on prototypical inheritance and instead we use functional instantiation to create the object. Once instantiated a variable loses its connection to the shared methods. So, any modification there will not be passed along to instances instantiated before the change.

If this is a problem we can still use prototypal inheritance and composition together to add new properties to prototypes after they are created and thus making them available to all the objects which delegate to that prototype.

An arrow function expression can no longer be used since it does not have a constructor method build in.

function Vegetable(name) {
  this.name = name
 return Object.assign(
    this,
    water(),
    harvest()
  )
}
const Carrot = new Vegetable('Carrot')

To Conclude

Composition is helpful when we are describing a “has a” relationship, while inheritance is useful in describing a “is a” relationship.

Both encourage code re-usability. On occasion, depending on the requirements and solution an inheritance can make sense.
But the vast majority of solutions will require you not just to think about the current requirements but what requirements will be needed in the future, in which case composition should more often than not win out the day.

And there we have it. I hope you have found this useful and thank you for reading. If you enjoyed this and found this helpful you may also enjoy some of the swag ideas we created at !!nerdy. New designs are launched every month.

Dynamic Javascript Form with Error Handling and Validation

Gavin Macken — Thu, 23 Sep 2021 21:29:42 +0000

One form to rule them all with React, Typescript, hooks, react-hook-form, material UI, and Yup.

Forms are a crucial part of most web application and is the predominant way users input and submit data. This means it often appears on multiple pages and components throughout an application.

The forms will likely contain many similar input fields and expected behaviors with regards to validation, type checking, form submission, and error handling.

All this repetitive code can increase technical debt and is much more difficult to create tests for.

The dynamic form solution I created makes it simple to reuse a form on different screens and views. The properties for each form are stored in an Object array and can be passed as props into the custom form component.

The form component uses Yup for form validation and react-hook-form to handle form submission and error-handling. Typescript is used for type checking, and material UI component library provides the form components and styles.

I hope it helps you

Dynamic form, Validation, Type checking, and Error handling.

JavaScript Instantiation in 5 mins

Gavin Macken — Wed, 22 Sep 2021 20:36:40 +0000

Effective instantiation patterns in JavaScript and how to use them.

Instantiation refers to the creation of an object. There are multiple patterns that have evolved over time that are used to achieve this. When instantiation patterns are used correctly they can effectively manage inheritance and provide greater code re-usability when creating multiple instances of objects.

Effective patterns can reduce the amount of code we write, the amount of code in memory, and the readability of your code to other devs.

We are going to look at how some of the generally accepted patterns can be created.

Functional Instantiation

This involves creating an empty object, assigning its properties and methods, and then returning the object.

It is the most basic and some might easiest to read form of instantiating.

Every time Plant is instantiated, the code inside that function is duplicated. That means that every single instance of Plant has its own copy of the water and repot method for example.

That’s not such a big deal in our case where we have only a few copies, but it's not optimal when you have hundreds or thousands of instances.

Another potential problem is there is no shared lineage since each instance is distinct, if you wanted to change something, you’d need to do it for every single instance.

// Functional
function Plant(name, size, flowerColor) => {
  var obj = {};
  obj.name = name;
  obj.size = size;
  obj.flowerColor = flowerColor;

  obj.water = function(){
    // Code to water plant
    console.log("Water the " + this.name)
  }

  obj.repot = function(){
    // Code to repot Plant
    console.log("Repotting")
  }

  return obj;

}

var daffodil = Plant("daffodil", "medium", "yellow")
console.log(daffodil.water()) // Water the daffodil

Functional Shared Instantiation

Like functional invocation in many ways but different in many important ways as well.
With shared functional instantiation, we are able to share methods and properties across all the instantiated objects without unnecessarily storing them in memory. Here I constructed an _extends method in order to achieve that.

Problems arise if I need to change the shared methods and properties. Once instantiated a variable loses its connection to the shared methods. So, any modification there will not be passed along to instances instantiated before the change.

// Functional Shared
function _extend(obj){
  var objects = arguments;
  Object.assign(obj, ...objects)
  return obj
}
function Plant(name, size, flowerColor) {
  var obj = {};
  obj.name = name;
  obj.size = size;
  obj.flowerColor = flowerColor;

  _extend(obj, plantMethods)

  return obj;
}
var plantMethods = {

  water: function(){
    // Code to water plant
    console.log("Water the " + this.name)
  },

  repot: function(){
    // Code to repot Plant
    console.log("Repot the plant")
  }

}

Prototypical Instantiation

Before we look at this pattern we should first understand the prototypical nature of JS. JS, been a prototypical-based language behaves differently from classical class-based languages such as Java or PHP.

Instead of classes inheriting from classes, objects can inherit from objects. This is achieved through a prototype property is present on every object. This property contains a constructor as well as other built-in methods that are shared via the prototype chain. Prototypical-based languages can be more expressive and provides a richer set of patterns.

ECMAScript 5 introduced a new method: Object.create(). Calling this method creates a new object. But most importantly what Object.create does is attach methods and properties to the object’s prototype instead of being returned within the object. Every method is available to every object created without duplicating methods in memory.

The method allows us to directly set the __proto__ property in a way that is a single event, which permits the browser to further optimize the object. It also allows the creation of objects without a prototype, using Object.create(null).

function Plant(name, size, flowerColor) {
  var obj = Object.create(plantMethods)
  obj.name = name;
  obj.size = size;
  obj.flowerColor = flowerColor;

  return obj;
}
var plantMethods = {

  water: function(){
    // Code to water plant
    console.log("Water the " + this.name)
  },

  repot: function(){
    // Code to repot Plant
    console.log( "Repot the plant")
  }

}
var daffodil = Plant("daffodil", "medium", "yellow")
console.log(daffodil.water()) // Water the daffodil

The slow object initialization can be a performance black hole if using the second argument, because each object-descriptor property has its own separate descriptor object. When dealing with hundreds of thousands of object descriptors in the form of objects, that lag time might become a serious issue.

Pseudo-Classical Instantiation

Pseudo classical instantiation attempts to overcome the amount of typing required to create an object using prototypal instantiation. Like prototypal, Pseudo classical instantiation utilizes the prototype chain.

But, best of all is there is a significant reduction in the amount of code that we would normally contribute because JavaScript does all the following work for us under the hood.

*Creates a new object.
*Binds the this keyword to that new object.
*Sets the new object’s __proto__, or internal prototype property, to be the prototype of the constructing function.
*At the end of the function, if no other return is specified, returns this (the new object).

function Plant(name, size, flowerColor) {
  this.name = name
  this.size = size;
  this.flowerColor = flowerColor;
}
Plant.prototype.water = function(){
   // Code to water plant
   console.log("Water the " + this.name)
}
Plant.prototype.repot = function(){
   // Code to repot Plant
   console.log("Repot the plant")
}
var daffodil = new Plant("daffodil", "medium", "yellow")
console.log(daffodil.water()) // Water the daffodil

ES6 Pseudo-Classical Instantiation

ECMAScript 2015 introduced a new set of keywords implementing classes. The new keywords include class, constructor, static, extends, and super.

Essentially, classes allow us to replicate a classical approach to instantiation. However, If we were to look under the hood we would see it still works the same way. It will still contain an internal prototype property and return this as the new object.

class Plant{
 constructor(size, flowerColor){
  this.size = size;
  this.flowerColor = flowerColor;
 }

 water(){
   // Code to water plant
    console.log("Water the " + this.name)
 }

 repot(){
   // Code to repot Plant
    console.log( "Repot the plant")
 }
}

var daffodil = new Plant("daffodil", "medium", "yellow")
console.log(daffodil.water()) // Water the daffodil

And there we have it. I hope you have found this useful. Thank you for reading. If you enjoyed this and found this helpful you may also enjoy some of the swag ideas we created at !!nerdy. New designs are launched every month.