Difference between revisions of "Quality assurance"
| Line 15: | Line 15: | ||
which the breakage occurred. | which the breakage occurred. | ||
| − | + | Idea of a test script: | |
cd test_directory | cd test_directory | ||
| Line 21: | Line 21: | ||
cvs co core | cvs co core | ||
cd core | cd core | ||
| − | ./build-all GNUstep-test-root &> test-log.txt | + | ./build-all $test_directory/GNUstep-test-root &> test-log.txt |
| − | |||
| − | |||
Revision as of 08:01, 24 February 2005
Introduction
Sometimes the GNUstep does not work as expected or can not be built at all. If the actual code which gets committed (which IMHO is really a basline requirement) was tested then this should not happen. Things which break the entire build cycle should be taken more seriously.
Aperez: I'd also like to set this up for win32, since that seems to be the thing that breaks fairly often as other patches go into -core.
Compilability test
As it is frustrating to check out CVS and have it fail to build for such a trivial reason.
Some sort of automated QA mechanism is necessary, where, upon a new CVS check-in to -base, for example, it is be checked out by an automated QA system and compiled on Linux/x86 as a baseline test. The results of the compilation would be placed on a webpage. If compilation breakage to any part of -core happened, a message would be sent to -dev notifying the core team that this had happpened, the offending file, and the version of the file in CVS at which the breakage occurred.
Idea of a test script:
cd test_directory rm -rf core GNUstep-test-root cvs co core cd core ./build-all $test_directory/GNUstep-test-root &> test-log.txt