webpack4. 0 each break (9) — karma chapter

Time:2021-12-29

I Web pack and automated testing

webpackThe corresponding keyword is modularity. Its main task is to package and manage modules, so the first concept to be clear iswebpackAutomated tests are associated becauseIt can provide module management capabilities for test scriptsIn essence, it iswebpackThe packaging function of is embedded in the automation test framework, rather than integrating the automation test framework as a plug-inwebpack, understanding this difference is critical.

aboutKarma+Mocha+ChaiAnd other automated testing related tools will be discussed inAutomation factory of large front endDescribed in the series of blog posts, this article mainly introduceskarma-webpackConnector, which connects automated testing and automated construction at the tool implementation level.

II karma-webpack

Plug in address:https://github.com/webpack-contrib/karma-webpack

2.1 introduction to automation unit test library

First, give a brief description of the basic unit test tools:

  • KarmaThe test framework provides the ability to run unit tests in a multi browser environment, includingheadlessbrowser.
  • MochaTest framework, which provides unit test capability compatible with browser and node environment, and can be usedkarma-mochaIntegrated intoKarmaYes.
  • ChaiAssertion library, supportshould,expect,assertDifferent types of assertion test functions can be usedkarma-chaiIntegrated intoKarmaYes.

Most unit tests are based on the joint use of the above three libraries.Karma-webpackThe main capability provided is forKarmaThe test scripts loaded in provide the ability of modular loading.

2.2 basic use

useyarn add karma-webpack -DFor installation,karma.conf.jsThe configuration file is as follows:

module.exports = (config) => {
  config.set({

    files: [
      //For all test files in the test directory that meet the naming criteria
      { pattern: 'test/*_test.js', watched: false },
      { pattern: 'test/**/*_test.js', watched: false }
    ],

    preprocessors: {
      //Specify the preprocessor for the selected script. All test scripts configured here need to be processed by webpack
      'test/*_test.js': [ 'webpack' ],
      'test/**/*_test.js': [ 'webpack' ]
    },

    webpack: {
      //Webpack configuration, the compilation configuration for test script packaging, is not related to project file packaging
      //You can also import a separate configuration file
    },

    webpackMiddleware: {
      //If you use webpack dev server, you can pass in some parameters
      stats: 'errors-only'
    }
  })
}

In this configurationwebpackEach hit file will be treated as aentryIn other words, it only handles local dependency management. The advantage of this is that it can run unit tests separately for some test scripts, but the disadvantage is also obvious, that is, when the number of test scripts is large and all test cases need to be run by default (for example, LLT tests triggered automatically on the automation pipeline), the efficiency is relatively low.

2.3 default scenario of running all test cases

In view of the above problems,webpakIt provides another optional method to process the test script set. It is easy to imagine that it is actually to create a new one by yourselfentryPoint, all the test scripts to be run are imported and packaged into onebundle.jsFile, its advantages and disadvantages are just the opposite of the basic scenario.

In this scenario,karma.conf.jsYou only need to configure for the portal file:

files: [
  // only specify one entry point
  // and require all tests in there
  'test/index_test.js'
],

preprocessors: {
  // add webpack as preprocessor
  'test/index_test.js': [ 'webpack' ]
},

Then create a new entry script under the root directory of the test fileindex_test.js:

//This configuration is for test / * * /_ test. JS format script file
const testsContext = require.context(".", true, /_test$/);
testsContext.keys().forEach(testsContext)

III Test report

Generally, after running the unit test, you need to output a report in the specified format for later self inspection or problem tracing. Here, you should pay attention to when andwebpack4.0When used in combination,karmaSome of the default behaviors of will fail (for example, outputting unit test cases and result summaries on the console, andkarmaA plug-in used by the stand-alone runtime to generate code coverage reportskarma-coverageIt also does not work properly), and it needs to be reconfigured here.

  • Unit test report

    If the unit test information cannot be output, you can explicitly reference the plug-inkarma-spec-reporterorkarma-mocha-reporterAnd carry out basic configuration.

  • Code coverage report

    The automatic generation and configuration of code coverage report is complex and needs to rely on the front-end code coverage toolistanbulCombined with several plug-ins. Lower versionwebpackCan refer tokarma-webpack-exampleThis open source project is configured as an example.webpack4.0The above versions can refer to the examples recommended below.

    Unit test results:

J

Coverage report:
2.png

IV Configuration reference

The author provideswebpack4.0 + karmaAn example of automated test configuration forWebpack4-Karma-Mocha-Chai-Demo, you can view it yourself if you need it.

Author: Da Shi doesn’t speak
Link:webpack4. 0 each break (9) — karma chapter
Source: blog Garden
The copyright belongs to the author. For commercial reprint, please contact the author for authorization, and for non-commercial reprint, please indicate the source.

Recommended Today

Springboot distributed session sharing

1、 In distributed development, the traditional method of nginx load balancing is to manually save the session to redis 1. common practices redis The client initiates a request. After the request reaches nginx, nginx forwards it to tomcata, and then tomcata saves a copy of data (redis) to the session. Next time, another request is […]