Files
Saber Haj Rabiee 8bc4fd4198 Introducing cargo all-features clippy|nextest part of build process (#3767)
* fix: intoducing cargo all-features clippy

* fix: change check to clippy for better diagnostics

* chore: build is redundant

* fix: lint task

* feat: speed up tests by 2x with cargo-nextest

* fix: re-add flags

* fix: router example build process

* fix: correct clippy arguments

* fix: adapt examples makefile to new tools

* fix(CI): add cargo-all-features part of CI dep

* fix: just warn if there is no tests

* fix(CI): add clippy and rustfmt components

* fix: nextest in examples

* fix: clippy should not run on empty set of features in examples
(quickfix)

* fix: pin cargo-all-features installation to a branch

* fix: nextest --no-tests=warn?

* fix: do not use built-in cargo-make workflows

* fix: remove --all-targets

* fix: do not run tests in parallel in certain examples

* fix: disable nextest for examples

* fix: properly override the make task

* chore: run tests with no-deps

* fix: hackernews_islands_axum

* fix(CI): properly use --no-deps

* fix(CI): --no-deps is not supported in tests

* fix(CI): run doctests separately due to stable rust limitation in nextest

* fix(examples): makefile lint recursion

* fix(CI): run tests correctly

* fix: remove unused clear in test makefile

* fix: --no-deps positional arg in clippy

* fix: run doctests for all-features

* fix: running cargo-all-features over doctests

* fix: improve playwright makefile
2025-04-07 08:57:01 -07:00
..
2024-08-10 20:01:41 -04:00

E2E Testing

This example demonstrates e2e testing with Rust using executable requirements.

Testing Stack

Role Description
Cucumber Test Runner Run Gherkin specifications as Rust tests
Fantoccini Browser Client Interact with web pages through WebDriver
Cargo Leptos Build Tool Compile example and start the server and end-2-end tests
chromedriver WebDriver Provide WebDriver for Chrome

Testing Organization

Testing is organized around what a user can do and see/not see. Test scenarios are grouped by the user action and the object of that action. This makes it easier to locate and reason about requirements.

Here is a brief overview of how things fit together.

features
└── {action}_{object}.feature   # Specify test scenarios
tests
├── fixtures
│   ├── action.rs               # Perform a user action (click, type, etc.)
│   ├── check.rs                # Assert what a user can see/not see
│   ├── find.rs                 # Query page elements
│   ├── mod.rs
│   └── world
│       ├── action_steps.rs     # Map Gherkin steps to user actions
│       ├── check_steps.rs      # Map Gherkin steps to user expectations
│       └── mod.rs
└── app_suite.rs                # Test main