Browser Testing vs Javascript Testing Framework

Bài đăng này đã không được cập nhật trong 2 năm

JS tests tend to be limited, hard to implement, and slow, so many front-end developers don't want to make JS tests. In some circumstances, TDD is known as the process of back-end development because there are much many framework help back-end developers to create the testing processes, the most specifically framework that I'm using every day in Ruby language is RSpec, it has many documentations, active communities. In contrast to Javascript tests, I have recently been using Jest - a testing framework made by Facebook.

As you can see, their slogan promises a “painless” JavaScript Testing. And indeed, Facebook have an excellent reason to use this slogan. In general, JS developers are not too happy with website testing. Nevertheless, with the right strategy and the right combination of tools a nearly full coverage can be achieved and tests can be very organized, simple, and relatively fast. I will point out some testing definitions, this is not only for front-end development but also back-end, so please read carefully

Test types

Unit Tests - Testing of individual functions or classes by mocking input and making sure the output is as expected.
Integration Tests - Testing several modules to ensure they work together as expected.
Functional Tests - Testing a scenario on the product itself (on the browser, for example) regardless of the internal structure to ensure expected behavior.

So, what is the differences between browser testing and JS testing framework?

JS testing frameworks

If it's called a framework, it should be an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. What are JS testing frameworks currently providing?

Provide a test environment (Mocha, Jasmine, Jest, Karma)
Provide a testing structure (Mocha, Jasmine, Jest, Cucumber)
Provide assertions functions (Chai, Jasmine, Jest, Unexpected)
Generate, display, and watch test results (Mocha, Jasmine, Jest, Karma)
Generate and compare snapshots of component and data structures to make sure changes from previous runs are intended (Jest, Ava)
Provide mocks, spies, and stubs (Sinon, Jasmine, enzyme, Jest, testdouble)
Generate code coverage reports (Istanbul, Jest)

Testing structure refers to the organization of your tests. Tests are usually organized in a BDD structure that supports behavior-driven development (BDD). It often looks like this:

describe('calculator', function() {
  // describes a module with nested "describe" functions
  describe('add', function() {
    // specify the expected behavior
    it('should add 2 numbers', function() {
       //Use assertion functions to test the expected behavior    
    })
  })
})

In each project, you always need a synchronized project which helps easy to maintain, read the code. Furthermore, the same testing structure and syntax, assertion functions, result reporting, and watching for all of them. Sometimes even the same testing environment can be used for some or all of them. Your JS tests should be organized like this:

For unit tests, provide all units with a mocked input and make sure their output is expected, Also make sure to use a** coverage reporting** tool to know what units are covered.
For integration tests, define important cross-module internal scenarios. Comparing to unit tests, you would use spies and stubs to test expected behavior instead of just asserting the output.

Functional Tests

Testing a scenario on the product itself (on the browser, for example) regardless of the internal structure to ensure expected behavior. For functional tests, A browser or browser-like environment with a programmable API will be used to create user-like behavior scenarios. The number of permanent tools for this purpose is somehow limited, and their implementation differs very much from each other, so it is strongly suggested to try implementing some of them before taking a decision.

In short, if you want to “just get started” with the most simple set-up, and if you want to test many environments easily, go with TestCafe.

If you want to go with the flow and have maximum community support, if you need to be able to write tests not only in JS, Selenium is the way to go.

If your application has no complex user interaction and graphics, for example, if you want to test a system full of forms and navigations, headless browser tools like Casper will provide you with the fastest tests.

Community comparison sometimes makes your decision.

In this very short article, we saw the most trending testing strategies and tools in the JS community and hopefully made it easier for you to test your application. You can look at the statistic of every single testing framework on stackshare then decide which one would you like to use in your project.