|
|
@ -22,21 +22,45 @@ or are controversial. |
|
|
|
|
|
|
|
|
|
|
|
The master branch is regularly built and tested, but is not guaranteed |
|
|
|
The master branch is regularly built and tested, but is not guaranteed |
|
|
|
to be completely stable. Tags are regularly created to indicate new |
|
|
|
to be completely stable. Tags are regularly created to indicate new |
|
|
|
official, stable release versions of Bitcoin. If you would like to |
|
|
|
official, stable release versions of Bitcoin. |
|
|
|
help test the Bitcoin core, please contact QA@BitcoinTesting.org. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Feature branches are created when there are major new features being |
|
|
|
Testing |
|
|
|
worked on by several people. |
|
|
|
======= |
|
|
|
|
|
|
|
|
|
|
|
From time to time a pull request will become outdated. If this occurs, and |
|
|
|
Testing and code review is the bottleneck for development; we get more |
|
|
|
the pull is no longer automatically mergeable; a comment on the pull will |
|
|
|
pull requests than we can review and test. Please be patient and help |
|
|
|
be used to issue a warning of closure. The pull will be closed 15 days |
|
|
|
out, and remember this is a security-critical project where any |
|
|
|
after the warning if action is not taken by the author. Pull requests closed |
|
|
|
mistake might cost people lots of money. |
|
|
|
in this manner will have their corresponding issue labeled 'stagnant'. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Issues with no commits will be given a similar warning, and closed after |
|
|
|
Automated Testing |
|
|
|
15 days from their last activity. Issues closed in this manner will be |
|
|
|
----------------- |
|
|
|
labeled 'stale'. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Requests to reopen closed pull requests and/or issues can be submitted to |
|
|
|
Developers are strongly encouraged to write unit tests for new code, |
|
|
|
QA@BitcoinTesting.org. |
|
|
|
and to submit new unit tests for old code. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unit tests for the core code are in src/test/ |
|
|
|
|
|
|
|
To compile and run them: |
|
|
|
|
|
|
|
cd src; make -f makefile.linux test |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unit tests for the GUI code are in src/qt/test/ |
|
|
|
|
|
|
|
To compile and run them: |
|
|
|
|
|
|
|
qmake BITCOIN_QT_TEST=1 -o Makefile.test bitcoin-qt.pro |
|
|
|
|
|
|
|
make -f Makefile.test |
|
|
|
|
|
|
|
./Bitcoin-Qt |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Every pull request is built for both Windows and |
|
|
|
|
|
|
|
Linux on a dedicated server, and unit and sanity |
|
|
|
|
|
|
|
tests are automatically run. The binaries |
|
|
|
|
|
|
|
produced may be used for manual QA testing |
|
|
|
|
|
|
|
(a link to them will appear in a comment on the pull request |
|
|
|
|
|
|
|
from 'BitcoinPullTester'). |
|
|
|
|
|
|
|
See https://github.com/TheBlueMatt/test-scripts for the |
|
|
|
|
|
|
|
build/test scripts. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Manual Quality Assurance (QA) Testing |
|
|
|
|
|
|
|
------------------------------------- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Large changes should have a test plan, and should be tested |
|
|
|
|
|
|
|
by somebody other than the developer who wrote the code. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See https://github.com/bitcoin/QA/ for how to create a test plan. |
|
|
|