Skip to content

Latest commit

 

History

History
71 lines (41 loc) · 3.19 KB

CONTRIBUTING.md

File metadata and controls

71 lines (41 loc) · 3.19 KB
Raw

Contributing

Your help is more than welcome! Even just open an issue to ask a question may greatly help others.

We use Github Projects to manage tasks. You can see the priority and progress of the issues there.

It's better to learn the basics of Go Testing, Sub-tests, and Test Suite first.

You can get started by reading the unit tests by their nature hierarchy: Browser -> Page -> Element.

So the reading order may like browser_test.go -> page_test.go -> element_test.go.

Run tests

The entry point of all tests is the setup_test.go file.

Example to run a single test

go test -v -run /Click, Click is the pattern to match the test function name.

Use regex to match and run a single test: go test -v -run /^Click$.

To disable headless mode

rod=show go test -v -run /Click.

To lint the project

go generate # only required for first time
go run ./lib/utils/lint

Code Coverage

If the code coverage is less than 100%, the CI will fail.

Learn the basics first.

To cover the error branch of the code you can intercept cdp calls. There are several helper functions in the setup_test.go for it:

  • stubCounter
  • stub
  • stubErr

To run inside docker

  1. docker build -t rod -f lib/docker/test.Dockerfile .

  2. docker volume create rod

  3. docker run --rm -v rod:/root -v $(pwd):/t rod go test -v -run /Click

Parallel execution of tests

Because we check goroutine leak on each test, parallel execution will pollution the global goroutine stack. You can't have your cake and eat it. By default, we trade speed for safety.

To enable parallel execution, you can use the -short flag, for example: go test -short. When it's enabled, the goroutine leak detection for each test will be disabled, but the detection for the whole test program will still work as well.

Convention of the git commit message

The commit message follows the rules here. We don't use rules like Conventional Commits because it's hard for beginners to write correct commit messages. It will encourage reviewers to spend more time on high-level problems, not the details. We also want to reduce the overhead when reading the git-blame, for example, fix: correct minor typos in code is the same as fix minor typos in code, there's no need to repeat content in the title line.

Become a maintainer

At the early stage of this project, we will use a simple model to promote contributors to maintainers. Anybody who has contributed code or doc to the project can get write access to issues and PRs contributors. Maintainers will have all the permissions of this project, only the first 2 maintainers are granted by the owner, then we will start to elect new maintainers by voting in the public issue. If no one votes down and 2/3 votes up then one election will pass.