Object-Oriented JavaScript — Observers and Tests

JavaScript is partly an object-oriented language.

To learn JavaScript, we got to learn the object-oriented parts of JavaScript.

In this article, we’ll look at some basic design patterns and tests.

Observer Pattern

The observer pattern is where we observe the changes from the one source by subscribing to an object and publish the changes to the observers that subscribed when there’re changes.

We can create an object that takes observers and publish changes to them by writing:

const observer = {
  subscribers: [],
  addSubscriber(callback) {
    if (typeof callback === "function") {
      this.subscribers.push(callback);
    }
  },

  removeSubscriber(callback) {
    const index = this.subscribers.findIndex(s => s === callback);
    this.subscribes.splice(index, 1);
  },

  publish(obj) {
    for (const sub of this.subscribers) {
      if (typeof sub === 'function') {
        sub(obj);
      }
    }
  },
};

We create an observer object that takes callbacks.

callback is a function that we add to the subscribers array.

Also, we have the removeSubscriber array to remove a callback.

publish takes an object with something to publish and callbacks the callbacks in the this.subscribers array to publish the changes.

Then we can use it by writing:

const callback = (e) => console.log(e);
const callback2 = (e) => console.log(2, e);
observer.addSubscriber(callback);
observer.addSubscriber(callback2);
observer.publish('foo')

We created 2 callbacks and add them to the subscribers array with the addSubscriber method.

Then we call publish to call the callbacks, which log the changes.

We should see:

foo
2 "foo"

logged in the console log.

The observer pattern is good since there’s not much coupling between the callbacks and the observer object.

We just call the callback when there’s some information to send to them.

The callbacks know nothing about the observer .

Testing

Testing is an important part of writing JavaScript apps.

We can make our lives easier by writing tests that run automatically.

Not having enough tests is a bad idea.

With tests, we make sure that the existing code behaves as per our specifications.

And any new code changes didn’t break existing behavior defined by our spec.

With tests, we don’t have to test everything ourselves by hand.

Also, we won’t have to check everything ourselves again when we refactor.

If our changes make the tests fail, then we know there’s something wrong.

Unit Testing

Unit testing is what we have the most of.

They’re short and they run fast.

They test the output given some input.

And they should be self-explanatory, maintainable and readable.

They should also work the same way in any order.

Test-Driven Development

Test-driven development is used a lot recently,

The methodology workflow starts by writing some tests that fail.

And then we write code to make the tests pass.

Then we run the tests again to see if they pass.

And then we refactor our code and make sure our tests still pass.

Behavior Driven Development

Behavior-driven development is a methodology where we create tests to test how our code behaves.

We test with some inputs and check th outputs.

Conclusion

We can create unit tests to test our code.

Also, the observer pattern lets us create loosely coupled code that communicates from the observer to another object.