Testing Development Builds
If you don't know how to write code, make art or translate, you can still help us by testing the development version of Widelands.
If you can't compile Widelands yourself
If you can compile
If you know how to compile Widelands or think you can learn, you can help us with testing branches that haven't been included in the current development version yet.
Selecting a branch to test
You can find a list of branches that need testing in the pull requests section on GitHub. We will sometimes also ask for testing on the forums when we have bigger projects that need thorough testing, or if we're changing the design of something.
Getting the branch
Open a terminal and if you have't done so already, you will need to clone the repository:
git clone https://github.com/widelands/widelands.git
You can then enter the directory by calling
cd widelands and switch to the branch by calling
git checkout <branchname>
More detailed explanations on how to use Git are available in our GitPrimer.
Compiling and running the branch
For testing, we will want to create a development build. These are the terminal commands that you would most typically run:
git checkout <branchname> ./compile.sh ./widelands
For more information on how to compile, see Building Widelands.
Testing the branch
Once you have finished compiling or installing your development build, it is time to do the actual testing.
Read the description of the change, then click on anything that you think might be affected in any order that you can think of - be creative. Depending on what the change is, you might also want to test both a single player and a multiplayer game and play with the settings. Some changes will also affect the tutorials, campaigns and scenario maps.
Hint: In debug builds, you can use the hotkey Ctrl-F3 to enable cheating mode. This allows you to change the amount of wares and workers in buildings for easier creation of complex setups for testing. The features unlocked by this hotkey are not compatible with replays and network games though.
Automated testing and codecheck
We have an automated test suite that you can run with development builds. We have some checks that run over the code itself to make sure that it adheres to our code style. See RegressionTests on how to run these tests.
Reporting your findings
- If we asked for testing on the forums, you can report your findings in the forum thread.
- If you tested the master branch, best report the bug in our issue tracker on GitHub. Search the issues first to make sure that it hasn't already been reported, and include the Widelands revision number. If you don't want to open an account on GitHub, you can also tell us about the bug in the forums.
- If you tested a branch that's undergoing code review, report your findings in the branch's Pull Request in the Pull requests section on GitHub.
- If everything has checked out, visit the "Files changed" tab and hit the green "Review changes" button. Write your comment, select "Approve" and submit your review.
- If there are still problems, describe them in the "Conversation" section.
See also How to Write a Good Bug Report.