“I just changed an if condition, not thinking that it would cause continuous integration to fail, deployment to fail, and affect other QA testing features.”

Improving the quality of Web applications is a very interesting topic. We know there are a number of ways to improve code quality, but for a variety of reasons, we don’t do it. In my first project, as we were all Junior consultants, we implemented a series of basic measures to improve the application quality, such as writing tests, pursuing test coverage, running pre-submitted scripts and so on.

In our most recent project, we faced a similar problem — we needed to improve the code quality of the project. Therefore, I want to write an article to introduce a related content. This article can be roughly divided into the following parts:

  • The quality of Web applications
  • Use testing to improve quality
  • Use Lint and Git Hooks to test your code
  • How to prevent hazard submission

So, let’s go back to the old “Web application quality problem.”

The quality of Web applications

Web applications often face a game between launch and quality — small bugs are often “tolerated” for projects as long as they don’t affect the user experience. This can be early online, to achieve user value. There are also development implications: one is the agile development cycle, the other is the multiple launches.

Therefore, Web development is different from software development in special fields and industries where a software that costs hundreds of millions to develop may only be run and deployed once and never get a second chance, such as the control system of an atomic bomb. There are also some types of cases, that is, the autonomous driving system on the intelligent car, the slightest mistake is the car hurt people busy. Web applications, while difficult to update, can be updated remotely. On these systems, however, quality is more important than speed of development. A Web application deployment failure can be rolled back, and although it costs money, it is rarely life-threatening.

So there is a delicate balance between quality and speed in Web development.

But software development is not just a matter of quality and speed. It is also a matter of product — that is, being able to make products that meet users’ needs. Then it becomes a more complex balance of mass, speed and demand. In order to deliver a product that is more in line with the user’s needs, you have to make frequent requirements changes. Depending on the timing of these changes, it tends to affect both code quality and development speed — the shorter a requirement is implemented, the shorter its testing time, and the higher the chance of bugs. I have encountered in the past, tonight online, the afternoon temporary change demand. As you can imagine, testers don’t have time to test.

At this point, continuous integration can only tell us explicitly that our tests are broken, that some of our functionality is broken, and that we should not deploy this new version. However, it’s not that continuous integration is broken and we can’t deploy, we can still deploy.

Blabla, so the question is, what’s the most effective way?

Use testing to improve quality

To ensure the quality of the project, after the code is submitted, it goes through a series of tests:

  • Unit testing
  • Automated UI testing
  • Developers do integration testing manually
  • Testers run three or four rounds of testing

If you look at testing on a project at a macro level, there are several stages of testing in an Agile project:

  • The Dev environment’s Desk Check is used to demonstrate whether the functionality meets the requirements.
  • Testing in the QA (test) environment for some general testing.
  • System Test (ST) Environment Test, which is used for joint commissioning with third-party systems. This environment is needed for integration when third-party systems appear.
  • Testing in the UAT (User Acceptance Test) environment, usually using code from the business side to verify whether the product meets the requirements.

If a Web application can pass this series of tests, its quality is guaranteed to some extent. So developers who don’t want to live too long can “irresponsibly” dump features on testers. Smile ~

However, in some companies, the Bug rate can affect performance, or there are so many bugs that it doesn’t look professional, etc. Blabla.

All in all, it’s friendlier for developers to write their own tests. According to the test pyramid, we need three types of tests:

  • Unit tests are used to make sure that our underlying functions are working properly.
  • Service testing, not only for its own services, but also for third-party dependent services.
  • UI tests, tests that mimic user behavior.

For a front-end project, we usually only need two types: unit tests and E2E tests. In fact, there should theoretically be testing of UI components, but generally speaking, when we choose UI components, we consider the stability of the components.

But in most domestic companies, writing tests is often impossible. At a lower level, we need a simpler and friendlier way to do this.

Use Lint and Git Hooks to test your code

There are a few more common things we can do before submitting the code:

  • Static code analysis (Lint), used for static code analysis, common examples being Lint4j, TSLint, ESLint.
  • To run the tests, in order not to affect continuous integration, we need to do the tests before the code is committed.

Modern editors (using plug-ins), ides can improve the technical means of static code analysis during development, and improve suggestions at any time. Intellij IDEA and WebStorm use TSLint to alert developers to specification issues with TypeScript code.

These analysis tools focus on code analysis. As described in the book Full Stack Application Development: Lean Practices, they typically perform a series of style checks:

  • Normalize function names and variables
  • Code format specification
  • Limiting language features
  • Function line limit
  • Multiple nesting restrictions
  • Unused code
  • , etc.

And these norms, if not enforced, are a game. Thus, we usually rely on Git Hooks to do this. For a project that uses Git to manage source code, Git Hooks do something like this, which can be viewed in the.git/ Hooks directory:

applypatch-msg     post-merge         pre-auto-gc        prepare-commit-msg
commit-msg         post-receive       pre-commit         push-to-checkout
post-applypatch    post-rewrite       pre-push           update
post-checkout      post-update        pre-rebase
post-commit        pre-applypatch     pre-receive
Copy the code

Generally speaking, there are only two phases in which we do things:

  • pre-commit, pre-local submission. Some syntax and Lint checking is usually done before the commit.
  • pre-push, pre-remote submission. Typically, some tests are run before this commit.

So, in our front-end project, we wrote these two scripts. The corresponding implementation is as follows:

{
    "precommit": "lint-staged"."prepush": "ng test && ng build --prod"
}
Copy the code

Precommit We formatted our code in conjunction with Lint-staged and Prettier:

  "lint-staged": {
    "src/app/*.{css,scss}": [
      "stylelint --syntax=scss"."prettier --parser --write"."git add"]."{src,test}/**/*.ts": [
      "prettier --write --single-quote"."git add"]}Copy the code

In fact, using ng Lint –fix is also a good way to do this.

We then test and Angular build production scripts before pushing the code, known as prepush. Because unit tests run fairly quickly, they can be completed in a matter of minutes, quickly responding to problems. Rather than waiting for continuous integration to break and then fix it.

Git, however, improves this option by providing a no-verify parameter. It allows developers to submit code without the validation above.

We often can’t stop people from doing this, especially when there are multiple teams working together.

Difficult to prevent hazard submission

Originally, I wanted to title it “Risky commit”, but I think risky commit is more reliable.

Common examples include going to dinner, going to work, going to a meeting, etc., and submitting the code before leaving. The functionality itself may be fine, but it blocks a sequence of subsequent actions.

Of course, the occurrence of not pit factors, such as earthquake, fire, etc., do not need to consider these things.

But with these specifications and practices, we can develop more stable Web applications.

conclusion

Development speed and quality is a difficult balance. At different times, we should make different technical decisions.