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
Un site qui demande des permissions aux navigateurs. Pratique pour tester rapidement.
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.