Improving the effectiveness of manual testing on VueJS

    Today I propose to address the issue of manual testing of projects on VueJS .

    Regardless of the level of automation of testing processes, there is almost always “live communication” between the tester and the future release. Naturally, it should be comfortable and effective.

    In our VueJS projects, we implemented simple but effective solutions that greatly simplified the lives of our testers. I want to share them with you.

    VueJS has a wonderful architectural feature - components. A component is a self-contained functional module, which in projects on VueJS is framed in a separate file with the extension .vue. The VueJS application itself is a collection of such modules.

    In fact, we can say that changing a single component leads to changing a single file. What forms the basis of the proposed solution.


    The idea is very simple - to visualize the tester with components in which there have been changes from the previous release / dev or the parent brunch (it is believed that the project has a repository). This will allow the tester to conduct testing more efficiently and efficiently, focusing on those components that have undergone changes and not waste time on a full regression.


    Because Since the component is a separate file, it’s enough to get the differences of the current commit and the target, i.e. the one with whom we are comparing to identify all modified components. To do this is simple, like this:

    git diff --no-commit-id --name-only -r 'origin/dev'

    Here we get the differences between the current commit and the 'origin / dev' branch as a list of modified files.

    The only thing left is to visualize these changes in the project to the tester.


    In this matter, webpack comes to the rescue , which makes it possible to assemble the project in different modes. We created for ourselves the “testing” mode, which became a fork of the standard “dev” mode (vue-cli application template) with the necessary improvements. In particular, we added getting a list of modified files:


    const exec = require('child_process').exec;
    var changedComponents = [];
    //Обновляем информацию о ветках
    exec("git fetch", function(error, stdout, stderr) {
     if (error) {
       throw error;
     //Выводим результат fetch
     console.log("\ngit fetch\n");
     //Получаем разницу с dev веткой
     exec("git diff --no-commit-id --name-only -r 'origin/dev'", function (error, stdout, stderr) {
       if (error) {
         throw error;
       //Выводим результат diff
       console.log("\ngit diff --no-commit-id --name-only -r 'origin/dev'\n");
       stdout.split("\n").map(function (file) {
         if (file.slice(-4) == '.vue' && (file.substring(0, 15) == 'src/components/' || file.substring(0, 11) == 'src/kernel/' )) {
           changedComponents.push('"' + file + '"');
    module.exports = changedComponents;

    And expanded env with this list:

    env.CHANGED_COMPONENTS = require('./git.diffs')

    Thus, we “skipped” the entire list of changes to the project and now were able to use it in runtime at our discretion. In particular, they introduced a global impurity that checks whether the component is included in the list of changes, and if so, then surrounds it with a red frame.

    export default {
     install (Vue, options) {
       let oldStyle = null;
         mounted () {
           if (this.isCodeChanged) {
             setInterval(() => {
               if (this.$el) {
                 if (store.state.system.isTesting()) {
                   if (!oldStyle) {
                     oldStyle = this.$ ? this.$ : 'empty';
                   this.$ = 'solid 3px #f00';
                 } else {
                   if ((!oldStyle || !oldStyle.length || oldStyle === 'empty') && this.$ {
                   } else {
                     this.$ = oldStyle;
             }, 300);
         computed: {
           vueComponentName () {
             return this.$options.__file;
           isCodeChanged () {
             return window.$testing.CHANGED_COMPONENTS.indexOf(this.$options.__file) >= 0;

    Note that there is a sign store.state.system.isTesting () in the code that turns on or off the visual demonstration mode of the changed component. It allows the tester to arbitrarily disable the display of component selection in order to check the layout.

    In fact, we have many similar features. To manage them, we created a specialized page where the tester can configure the testing environment online. It is also available in the “testing” build mode on the / testing direct route.

    As a result, the changed component looks like in the picture at the beginning of the article.

    Behind the scenes

    Of course, in addition to components that are rendered, there may be changes in service components. So that nothing escapes the eyes of the tester, we display the full list of modified files in the browser console at startup. It also displays information about the build time, build mode, current release, etc.

    Also popular now: