{"id":16337,"date":"2017-03-02T12:15:42","date_gmt":"2017-03-02T10:15:42","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=16337"},"modified":"2017-03-01T11:00:37","modified_gmt":"2017-03-01T09:00:37","slug":"test-driven-development-javascript","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/javascript\/test-driven-development-javascript\/","title":{"rendered":"Test-Driven Development For JavaScript"},"content":{"rendered":"

JavaScript is handsdown the strangest language I\u2019ve ever had to test. Its also one of the most popular<\/a> ones out there right now. The influx of JavaScript developers tells us that a lot of modern-day web development is starting to focus more and more on the frontend.<\/p>\n

This trend is interesting because it represents a shift in development that we\u2019ve never seen before. Our applications are being composed of more and more JavaScript. However, are we effectively testing all of this newfound client-side code?<\/p>\n

Sort of.<\/p>\n

I believe that we must follow a more robust methodology to test our growing JavaScript applications. Today, I want to explore the idea of practicing Test-Driven Development (TDD) for client-side JavaScript.<\/p>\n

What\u2019s So Different About Testing JavaScript?<\/h2>\n

In web development, we can separate our concerns into two sections: the client-side (stuff that happens in a user\u2019s web browser) and the server-side (things that happen on our application servers).<\/p>\n

When it comes to testing, we\u2019ve historically covered our server-side code with unit and functional tests and our client-side with integration tests. We tend to give a lot of thought and investment into server-side tests and simply verify the results with an integration test on the client-side.<\/p>\n

However, server-side code is and was never the complete picture of web development. What the user sees on the client-side is often what has the most impact. The most impressive technical features mean nothing if the view layer is messed up!<\/p>\n

Integration tests are helpful and effective when we\u2019re only concerned with what shows up on the webpage. It says nothing about what goes on inside the client-side code processing; it only shows the output of such logic.<\/p>\n

There was a period of time where integration tests could really serve as proper test coverage for what\u2019s going on in the client-side of our applications. However, with more and more applications having bigger shares of JavaScript, we\u2019ve got to come up with a better way of testing the client-side other than: is x<\/em> showing up on the page?<\/p>\n

To start things off, let\u2019s look at what\u2019s familiar about TDD on the client-side. It turns out a lot of things aren\u2019t that different after all!<\/p>\n

JavaScript TDD Isn\u2019t That Different<\/h2>\n

No matter how experienced in TDD you are, don\u2019t panic! If you\u2019ve done TDD before, applying it to client-side JavaScript isn\u2019t that different on a high level. With TDD, we want to stay true to a cycle of three steps:<\/p>\n

    \n
  1. Write tests that reflect the expected behavior of your code.<\/li>\n
  2. Write code to make those tests pass.<\/li>\n
  3. (optional) Refactor and ensure the tests still pass.<\/li>\n<\/ol>\n

    Let\u2019s run through a quick example in EmberJS.<\/p>\n

    A unit TDD example with EmberJS<\/h3>\n

    Ember is really cool because it comes with a lot of great tools for testing right out of the box. If you run something as simple as: ember g model user<\/code>, you\u2019ll be gifted with two important files: app\/models\/user.js<\/code> and tests\/unit\/user-test.js<\/code>. If you run ember test<\/code>, all of your tests related to user.js<\/code> should pass.<\/p>\n

    Currently, our files look something like this:<\/p>\n

    user.js<\/code><\/p>\n

    import DS from 'ember-data';\r\n\r\nexport default DS.Model.extend({\r\n\r\n});<\/pre>\n
    user-test.js<\/code><\/p>\n
    import { moduleForModel, test } from 'ember-qunit';\r\n\r\nmoduleForModel('user', 'Unit | Model | user', {\r\n  \/\/ Specify the other units that are required for this test.\r\n  needs: []\r\n});\r\n\r\ntest('it exists', function(assert) {\r\n  let model = this.subject();\r\n  assert.ok(!!model);\r\n});<\/pre>\n
    We want to expand our model to do two things: have a name and be able to retrieve a metric called \u201ckarma\u201d for a user. Let\u2019s write up some tests to reflect these desires:<\/p>\n
    user-test.js<\/code><\/p>\n
    import { moduleForModel, test } from 'ember-qunit';\r\n\r\nmoduleForModel('user', 'Unit | Model | user', {\r\n  \/\/ Specify the other units that are required for this test.\r\n});\r\n\r\ntest('it exists', function(assert) {\r\n  let model = this.subject();\r\n  assert.ok(!!model);\r\n});\r\n\r\ntest('must contain a name', function(assert) {\r\n  let model = this.subject({ name: 'testing name'});\r\n  assert.equal(model.get('name'), 'testing name');\r\n});\r\n\r\n\/\/ Note: Karma should be the combo of upvotes and downvotes against a user\r\ntest('should be able to retrieve the karma of a user', function(assert) {\r\n  let model = this.subject({ name: 'karma user', upvotes: 10, downvotes: 5});\r\n  assert.equal(model.get('karma'), 5);\r\n});<\/pre>\n
    If we\u2019ve changed nothing to user.js<\/code>, we\u2019ll find that our Ember test suite will now fail gracefully. Next up, we\u2019ll work to make these tests actually pass.<\/p>\n
    user.js<\/code><\/p>\n
    import Ember from 'ember';\r\nimport DS from 'ember-data';\r\n\r\nexport default DS.Model.extend({\r\n  name: DS.attr('string'),\r\n  upvotes: DS.attr('number'),\r\n  downvotes: DS.attr('number'),\r\n  karma: Ember.computed( function() {\r\n    return this.get('upvotes') - this.get('downvotes');\r\n  })\r\n});<\/pre>\n
    Now our tests and code are good to go!<\/p>\n
    With just a few simple steps, we were able to run through the TDD process and develop some simple but stable code! I chose not to refactor on this run through since my changes were pretty simple. However, the more complex our code becomes, the more there becomes a need for refactoring at every step.<\/p>\n
    Other frameworks and JavaScript code<\/h3>\n
    Not every JavaScript framework or codebase has a built-in test runner like EmberJS (or EmberCLI) has. There still are a lot of excellent tools out there like Mocha<\/a> and Jasmine<\/a>. However there\u2019s still a long way to go<\/a> when it comes to JavaScript test tooling.<\/p>\n
    While client-side unit testing doesn\u2019t look that different from other kinds of testing we\u2019ve experienced, there are some noticeable differences to how we should approach it.<\/p>\n
    Javascript TDD Is Different<\/h2>\n
    When implementing TDD on the client-side, we\u2019ll need to divide our testing mindset into client-side and server-side concerns.<\/p>\n
    Client-side JavaScript cannot query a database. It can make calls for a query or query data presented on the client-side. It cannot, however, directly fetch and insert into a database. This is important because we want to assume that the data being given to the client-side (in our tests) is gospel. We should treat the server-side data being sent as an external dependency on our test.<\/p>\n
    In many ways, we\u2019re splitting up our applications into two contained testing areas: Server-side tests are concerned with things that go on inside the server; client-side tests are concerned with stuff that happens in the web browser. In order to achieve proper test coverage of these two aspects, the amount of tests we\u2019re hauling along is going to increase. In some cases, we could have all of the following:<\/p>\n