TL;DR we don't care in unit tests about internal testing. That doesn’t mean shallow rendering is wrong.

I personally use them to test well separated logic and iterate over:

• write the test that make the feature pass
• implement until the code passes the test
• next feature or case or exception
• repeat.

Yes. TDD.

This repository contains the code for our paper: "Who's Breaking the Rules? Studying Conformance to the HTTP Specifications and its Security Impact" ACM ASIACCS 2024. It contains a test suite for HTTP conformance tests of responses and test runners to run it on both local web servers and on real websites.

About avoiding mock and writing tests that uses the database directly.

Hurl is a command line tool that runs HTTP requests defined in a simple plain text format.

It can asserts results.

In a nutshell, the purpose of REVENGE.CSS is to apply visual regressions to any markup anti-patterns. It makes bad HTML look bad.

Interesting.

Passing CSS variable errors can be useful too.

There are also useful patterns.

Simply run these scripts on the web page to trigger some actions.

• Validate HTML
• Calculate carbon
• WAVE
• PageSpeed
• SSL Report
• Security Headers

An example of API testing in Cypress

How to rotate items to test every day

An easy way to build flow on mobile to simulate user actions. Can it work for desktop web browsers? If yes, then it can become awesome.

The WPT Dashboard, wpt.fyi, displays results for the web-platform-tests, or WPT, which are a group of test suites for many web platform specifications.

If the web platform as a whole were an engineering project, it'd be crazy not to have a test suite that's run regularly. The goal of the WPT Dashboard is to promote viewing the web platform as one entity and to make identifying and fixing interoperability issues as easy as possible.

This separation between unit and integration became vague nowadays.
Instead we can think in term of purity and extent.

Purity → "corresponds to the amount of generalized IO the test is doing and is correlated with desirable metrics, namely performance and resilience."
Extent → "corresponds to the amount of code the test exercises. Extent somewhat correlates with impurity, but generally does not directly affect performance."

Schemathesis is a modern API testing tool for web applications built with Open API and GraphQL specifications.

When the test fails it also should provide enough information to understand which behaviour failed, where it failed, and (at least superficially) why it failed

👍‍ with 5 arguments provided

Unit > Integration > E2E is still a valid pyramid for testing; but better can be found.

Static analysis > Unit + Integration > e2e

Static analysis means to check the code without running it. We already have examples with Eslint as a javascript code style fixer; Stylelint for CSS code fixing (I have to try); Sonarqube

Unit and integration tests are mixed together as:

• The definition of a unit is often “to be discussed”: If you ask a group of developers to define a unit, you will mostly get various, differing answers. As some refer to a function, class, or service — minor units — another developer will count in the complete component.
• In addition to those definition struggles, drawing a line between unit and integration can be tricky, as it’s very blurry. This struggle is real, especially for Frontend, as we often need the DOM to validate the test basis successfully.
• It’s usually possible to use the same tools and libraries to write both integration tests. So, we might be able to save resources by merging them.

There are also visual tests. We can group e2e-tests and visual tests into a UI test category. Btw the recommended open-source and fully self-hosted tool for visual testing is Visual Regression Tracker

Indicate the scenario in each unit test: something I should definitely do