summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRémi Verschelde <rverschelde@gmail.com>2020-10-01 19:14:04 +0200
committerGitHub <noreply@github.com>2020-10-01 19:14:04 +0200
commit25ca77c3796602b52ee9dca98abbb35aa9ede773 (patch)
tree7032edbcaa6d0fe53da57ad0eac1b39f4b45d36b
parent17d588f7b3acf292daeae88dd3d95fa2f6240349 (diff)
parent8a84b3cfd352adac4c5a35d599be8d83db3ba8d9 (diff)
Merge pull request #42430 from Calinou/contributing-tests
Document contributing tests to Godot's C++ codebase
-rw-r--r--CONTRIBUTING.md23
1 files changed, 23 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c28692c34f..1abd76b2ff 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -135,6 +135,29 @@ If your pull request modifies parts of the code in a non-obvious way, make sure
to add comments in the code as well. This helps other people understand the
change without having to look at `git blame`.
+### Write unit tests
+
+When fixing a bug or contributing a new feature, we recommend including unit
+tests in the same commit as the rest of the pull request. Unit tests are pieces
+of code that compare the output to a predetermined *expected result* to detect
+regressions. Tests are compiled and run on GitHub Actions for every commit and
+pull request.
+
+Pull requests that include tests are more likely to be merged, since we can have
+greater confidence in them not being the target of regressions in the future.
+
+For bugs, the unit tests should cover the functionality that was previously
+broken. If done well, this ensures regressions won't appear in the future
+again. For new features, the unit tests should cover the newly added
+functionality, testing both the "success" and "expected failure" cases if
+applicable.
+
+Feel free to contribute standalone pull requests to add new tests or improve
+existing tests as well.
+
+See [Unit testing](https://docs.godotengine.org/en/latest/development/cpp/unit_testing.html)
+for information on writing tests in Godot's C++ codebase.
+
### Be nice to the Git history
Try to make simple PRs that handle one specific topic. Just like for reporting