Run a Test: Difference between revisions

From VrlWiki
Jump to navigation Jump to search
No edit summary
Jadrian Miles (talk | contribs)
No edit summary
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
<<< These are preliminary notes and may not be accurate. >>>
<<< These are preliminary notes and may not be accurate. >>>


# [[How the Test Scripts Work]].
Programs should have a simple test to ensure the most basic functions are workingThe test should run in a reasonable amount of time on par with the time it takes to build the programThese simple smoke tests need to be fully automated. Additional tests that are more comprehensive can also be provided, but need not be included as part of the automated test system.
 
* Launch $G/src/gfxtest/gfxtest from a designated test machine.
    Setup $G normally???
    Checkout src/gfxtest???
 
    src/gfxtest> ./gfxtest  [-noemail] [-notmp] [-d <result/]  mail,...
        -noemail - Do not email individual test reports to the recipients
                  in gfxtest.cfgBy default failed tests mail a notification.
                  Successful test runs never cause mail to be sent.
        -notmp  - Run tests in the current $G tree.  Administrative use only.
        -d      - Store output files here (default is $G_TMP/gfxtest).
 
* gfxtest runs:  $G/src/gfxscripts/gfxtree-init
    A partial copy of $G is created locally in /ltmp.
    The files are extracted from cvs.
    Separate duplicate copies are made for each supported architecture with:
        src/gfxtest/  src/gfxscripts  src/gfxtools-doc  src/make
    A copy of $G/data/ is made for WIN32 and the Unix copies link to it.
   
* $G is set in gfxtest to the test copy.
    linux: $G = /ltmp/gfxtest/gfx/tools/linux
    WIN32: $G = /tmp/gfxtest/gfx/tools/WIN32
 
* Tests are run on a test machines for each supported platform.
  Currently these machines are:  ???
 
* Script Files:
 
  $G/src/gfxtest/gfxtest.cfg
  $G/src/gfxtest/gfxtest
  $G/src/gfxscripts/gfxtree-init
 
* Output Files created on each test machine:
 
  $G_TMP/gfxtest/gfxtest-summary.txt
  $G_TMP/gfxtest/gfxtest-treeinit-output.txt
  gfxtest-$testcount-$testName-output.txt


# [[How the Test Scripts Work]]
#: An overview of the test mechanism.
# [[Subscribe to Test Results]]
# [[Subscribe to Test Results]]
 
#: Receive summaries of daily test runs or notifications when specific tests fail.
Tests are run daily and mail is sent when an individual tests fail.
A summary of each test run is sent as well.
 
* Subscribe to failure notifications for an individual test:
 
  Checkout and carefully edit: src/gfxtest/gfxtest.cfg
  Each line specifies a test to be run and contains:
 
      <testname> <testowners> <testarchs> <testcommand> <testcommandarg1> <..>; ...
 
      <testname> is a directory in $G/src/
      <testowners> mail recipient
      <testarchs> {linux | WIN32 | OSX | sol | sgi},...
      <testcommand> Commands to run a test separated by a semicolon.
            usually:  $G/bin/gfxtest-project <projectname>
 
  Blank lines are permitted.  There is no provision for comment lines.
 
* Subscribe to receive test summaries.
 
  To be filled in.
 
 
 
# [[Run the Project Tests Locally]]
# [[Run the Project Tests Locally]]
 
#: Manually run tests or schedule them to be run automatically.
To be filled in.
# [[Add a Test to a Project]]
 
#: Write tests for a project so they will work with the test driver.
 




[[Category:HOWTO]][[Category:$G]][[Category:Software Development]]
[[Category:$G HOWTO]][[Category:Software Development]]

Latest revision as of 22:57, 6 March 2009

<<< These are preliminary notes and may not be accurate. >>>

Programs should have a simple test to ensure the most basic functions are working. The test should run in a reasonable amount of time on par with the time it takes to build the program. These simple smoke tests need to be fully automated. Additional tests that are more comprehensive can also be provided, but need not be included as part of the automated test system.

  1. How the Test Scripts Work
    An overview of the test mechanism.
  2. Subscribe to Test Results
    Receive summaries of daily test runs or notifications when specific tests fail.
  3. Run the Project Tests Locally
    Manually run tests or schedule them to be run automatically.
  4. Add a Test to a Project
    Write tests for a project so they will work with the test driver.