Investigated and Summarized Testing Perspectives for Web Apps (25 Selections)

Recently, I learned about the term Property Based Test. I was curious about what other types of tests there are, so I looked into it. This article lists the types of tests. ※ The technology used is chosen in node.js for my convenience.

List of Test Perspectives

Cache Test

In web apps, various Caches are used. For example, browser Cache, CDN Cache, proxy Cache, backend Cache, etc. Cache is convenient, but if you use it too much, you will get lost as to where and how it is caching. It seems necessary to test the Cache in web apps as well.

https://github.com/http-tests/cache-tests

Code Size Test

Loading a large size JS library will degrade the response time. Therefore, it is necessary to always measure the code size.

https://github.com/ai/size-limit

Complexity Test

Cyclomatic complexity measures the complexity of control statements (such as if and for). Complex code tends to be a breeding ground for bugs, so we want to aim for as simple code as possible.

https://eslint.org/docs/rules/complexity

Copy&Paste Test

Copy&Paste is against the DRY principle, so unless there is a special reason, you should not do it. It seems there is a tool to detect Copy&Paste.

https://github.com/kucherenko/jscpd

Cross Browser/Platform Test

It is necessary to verify the operation of the supported browsers and platforms (iOS, Android, Desktop, etc.). Therefore, you need to prepare the environment for the supported browsers and platforms. There are services that allow you to easily use such environments.

https://github.com/browserstack

E2E Test

The web app is verified from end to end (End To End: E2E). For example, a user visits a web app, clicks or inputs, etc., to try it out. This test tends to be an unstable test (often fails), so efforts are needed to ensure stable operation. For example, abstraction of operations and data fixation, etc.

https://github.com/cypress-io/cypress

Exception Test

Tests such as normal, semi-normal, and abnormal are necessary. Semi-normal is something that the system intentionally errors, such as form input value errors. Abnormal is something that the system unintentionally errors, such as Timeout errors.

Also, for those who are good at Java, there are ways to handle exceptions such as checked exceptions and unchecked exceptions. Basically, it is a good policy to handle checked exceptions and not handle unchecked exceptions.

Flaky Test

This refers to unstable tests. One of the approaches to this is a document from Google.

https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45880.pdf

The following document was compiled by a Japanese person. https://speakerdeck.com/nihonbuson/flakytests

Integration Test

Integration Test is a verification that integrates single functions like Unit Test. Depending on the definition, I think it is "something that cannot be discovered in Unit Test". Even if it is not covered by Unit Test, if it can be verified by other tests, Integration Test is not necessary.

Logging Test

You need to verify that the log output is at the appropriate level. I'm curious whether INFO, WARN, ERROR, etc. are used according to the rules. Whether or not you can output logs will be a verification of the log library, so you may not need it, but I think it's okay to test whether the intended message is output at the intended log level at the intended timing.

Monkey Test

This is a monkey test where a monkey randomly tests. This test is done when it is difficult to cover all test patterns or when you want to make sure even if you can cover all patterns.

https://github.com/marmelab/gremlins.js/

Multi Tenant Test

Multi-tenant is a method of providing the same system distinguished for each company (user). This requires testing for each environment because it separates subdomains for each company.

Mutation Test

There is a mutation test to verify the test. You verify whether the test breaks by destroying the product code. If the test succeeds even if you destroy the product code, it is not being tested correctly.

https://github.com/stryker-mutator/stryker

Chaos Test

This is a test to verify what kind of behavior occurs when a failure is injected.

https://github.com/goldbergyoni/node-chaos-monkey

Performance Test

Even when we talk about performance, there are various indicators such as CPU usage, memory usage, response time, and RPS. It is necessary to measure these and verify whether they meet the standard values such as SLO.

https://github.com/bestiejs/benchmark.js/

Property Based Test

This is a method of semi-automatically generating data and testing it.

https://github.com/dubzzz/fast-check

Regression Test

A Regression Test is a test to check whether the content you have fixed unintentionally affects other areas (degradation). This test has a broad meaning, so I think there are many types of tests contained here.

Robustness Test

Web apps should be robust. Even if some failure occurs within the web app, it is preferable to provide at least a minimum service. Of course, let's return the status that was affected without setting the HTTP status to 200 at that time.

Security Test

Security testing is essential for any web app. Since I am not a security expert, I will omit what kind of test is necessary here.

The following command is effective for checking the vulnerability of dependent packages.

npm audit fix

SEO Test

SEO is essential to improve the number of inflows to the web app. It seems that you can see the SEO score with a tool called lighthouse.

https://github.com/GoogleChrome/lighthouse-ci

Smoke Test

A Smoke Test is a verification to secure the cases necessary for the web app to operate at a minimum. For example, if you request the top page, the response is returned with HTTP 200.

If this minimum operation guarantee is not available, you cannot perform more detailed tests. Personally, I think it will proceed in the order of Smoke Test → E2E Test.

Snapshot Test

Request the web app and save the HTML (snapshot) which is the response. The Snapshot test is to verify whether this HTML has changed compared to before the change. It is effective for refactoring and other changes that do not change.

https://jestjs.io/docs/ja/snapshot-testing

Static Test

A Static Test is a test that can be verified without running the web app. A common one is a Linter.

• HTML https://github.com/htmlhint/HTMLHint

• CSS

https://github.com/CSSLint/csslint

• JS

https://github.com/eslint/eslint

• SVG

https://github.com/birjolaxew/svglint

• Commit

https://github.com/conventional-changelog/commitlint

• Docker

https://github.com/RedCoolBeans/dockerlint/

These are good compatibility with Danger, which mechanically points out in pull requests.

https://github.com/danger/danger

Unit Test

There is a Unit Test that tests a single function. If all of these Unit Tests PASS, I think it is common to proceed with other tests.

https://github.com/facebook/jest

Code Coverage

In unit testing, you can see the coverage of what was tested. As a rule of thumb, I think it's good if you can cover about 80% of the whole.

https://jestjs.io/docs/en/cli.html#--coverageboolean

You can also collect coverage of the actual running JS and CSS.

https://speakerdeck.com/pirosikick/puppeteerdeiranaicsswoxiao-su

https://gist.github.com/silverbirder/71135913192fbca51a7e26924bd36b8b

Visual Regression Test

You need to monitor visual changes. For example, if there are broken links, you should detect them.

https://github.com/garris/BackstopJS

Finally

I wrote roughly from what kind of test perspectives there are, research, and experience. It's not necessary to test everything, but it's good to be conscious of "what kind of operational quality you want to guarantee" and make choices. Thank you for reading to the end.

If it was helpful, support me with a ☕!

Share

Related tags