Ignore:
Timestamp:
Oct 31, 2011, 5:13:52 PM (13 years ago)
Author:
Frederik Heber <heber@…>
Branches:
Action_Thermostats, Add_AtomRandomPerturbation, Add_FitFragmentPartialChargesAction, Add_RotateAroundBondAction, Add_SelectAtomByNameAction, Added_ParseSaveFragmentResults, AddingActions_SaveParseParticleParameters, Adding_Graph_to_ChangeBondActions, Adding_MD_integration_tests, Adding_ParticleName_to_Atom, Adding_StructOpt_integration_tests, AtomFragments, Automaking_mpqc_open, AutomationFragmentation_failures, Candidate_v1.5.4, Candidate_v1.6.0, Candidate_v1.6.1, ChangeBugEmailaddress, ChangingTestPorts, ChemicalSpaceEvaluator, CombiningParticlePotentialParsing, Combining_Subpackages, Debian_Package_split, Debian_package_split_molecuildergui_only, Disabling_MemDebug, Docu_Python_wait, EmpiricalPotential_contain_HomologyGraph, EmpiricalPotential_contain_HomologyGraph_documentation, Enable_parallel_make_install, Enhance_userguide, Enhanced_StructuralOptimization, Enhanced_StructuralOptimization_continued, Example_ManyWaysToTranslateAtom, Exclude_Hydrogens_annealWithBondGraph, FitPartialCharges_GlobalError, Fix_BoundInBox_CenterInBox_MoleculeActions, Fix_ChargeSampling_PBC, Fix_ChronosMutex, Fix_FitPartialCharges, Fix_FitPotential_needs_atomicnumbers, Fix_ForceAnnealing, Fix_IndependentFragmentGrids, Fix_ParseParticles, Fix_ParseParticles_split_forward_backward_Actions, Fix_PopActions, Fix_QtFragmentList_sorted_selection, Fix_Restrictedkeyset_FragmentMolecule, Fix_StatusMsg, Fix_StepWorldTime_single_argument, Fix_Verbose_Codepatterns, Fix_fitting_potentials, Fixes, ForceAnnealing_goodresults, ForceAnnealing_oldresults, ForceAnnealing_tocheck, ForceAnnealing_with_BondGraph, ForceAnnealing_with_BondGraph_continued, ForceAnnealing_with_BondGraph_continued_betteresults, ForceAnnealing_with_BondGraph_contraction-expansion, FragmentAction_writes_AtomFragments, FragmentMolecule_checks_bonddegrees, GeometryObjects, Gui_Fixes, Gui_displays_atomic_force_velocity, ImplicitCharges, IndependentFragmentGrids, IndependentFragmentGrids_IndividualZeroInstances, IndependentFragmentGrids_IntegrationTest, IndependentFragmentGrids_Sole_NN_Calculation, JobMarket_RobustOnKillsSegFaults, JobMarket_StableWorkerPool, JobMarket_unresolvable_hostname_fix, MoreRobust_FragmentAutomation, ODR_violation_mpqc_open, PartialCharges_OrthogonalSummation, PdbParser_setsAtomName, PythonUI_with_named_parameters, QtGui_reactivate_TimeChanged_changes, Recreated_GuiChecks, Rewrite_FitPartialCharges, RotateToPrincipalAxisSystem_UndoRedo, SaturateAtoms_findBestMatching, SaturateAtoms_singleDegree, StoppableMakroAction, Subpackage_CodePatterns, Subpackage_JobMarket, Subpackage_LinearAlgebra, Subpackage_levmar, Subpackage_mpqc_open, Subpackage_vmg, Switchable_LogView, ThirdParty_MPQC_rebuilt_buildsystem, TrajectoryDependenant_MaxOrder, TremoloParser_IncreasedPrecision, TremoloParser_MultipleTimesteps, TremoloParser_setsAtomName, Ubuntu_1604_changes, stable
Children:
5982c5
Parents:
19bc74
Message:

HUGE: Update on documenation.

  • a general skeleton of the documentation is now in place with all the major components of MoleCuilder explained to some extent.
  • some information has been transfered from TRAC (e.g. install procecure) into this doxygen documentation where it is general and not specific to the situation at our institute.
Location:
src/documentation/tests
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • src/documentation/tests/code-tests.dox

    r19bc74 r750cff  
    2222 * -# Every .cpp files must include \b config.h and \b CodePatterns/MemDebug.hpp
    2323 * -# Every .hpp files must include \b config.h
     24 * -# Every .dox file contains a (correctly formatted: YYYY-MM-DD) date stamp.
    2425 *
    2526 * These make sure that the memory debugger is catching every movement on the
    26  * heap and that every module knows about the behavior controling defines that
    27  * are checked by autoconf and written to \b config.h in the build directory.
     27 * heap and that every module knows about the behavior controling \e #define's that
     28 * are checked by autoconf and written to \b config.h in the build directory. And
     29 * also that for every documentation file it is known when it was current.
    2830 *
    29  * \section Directory structure
     31 * \section codetest-structure Directory structure
    3032 *
    3133 * The code tests are contained in \b tests/CodeChecks. Therein are all test
    … …  
    3335 * Mostly, these look through files
    3436 *
    35  * \section Launching all tests
     37 * \section codetest-launch-all Launching all tests
    3638 *
    37  *  TODO: Documentation - explain how to launch all code tests.
     39 *  In order to launch all tests, simply do:
     40 *  -# Enter \b tests/CodeChecks in your build directory
     41 *  -# Run
     42 *    \code make check \endcode
     43 *    there
    3844 *
    39  * \section Launching some tests
     45 * \section codetest-launch-some Launching some tests
    4046 *
    41  *  TODO: Documentation - explain how to launch some code tests
     47 *  Launching a single or just some of the tests is only a little bit more
     48 *  complicated. Proceed as follows:
     49 *  -# Enter \b tests/CodeChecks in your build directory
     50 *  -# Run
     51 *  \code ../../../tests/CodeChecks/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
     52 *  where \a <option> is explained in the subsections below and \a <buildpath> is
     53 *  the build path (i.e. the variable \a AUTOTEST_PATH should contain the path to
     54 *  the executable).
    4255 *
    43  * \section Inspecting results
     56 *  \subsection regressiontest-launch-by-number ... by number
    4457 *
    45  *  TODO: Documentation - explain how to inspect code test results.
     58 *    Tests can be launched by specifying their test number, e.g. then \a <option>
     59 *    might be \a 1 or \a 1-2 or just nothing for all of them.
     60 *
     61 *  \subsection regressiontest-launch-by-keyword .. by keyword
     62 *
     63 *    Tests may as well be launched by some keywords, e.g. each code check has
     64 *    a specific keyword which is given via \b AT_KEYWORD directive of Autotest.
     65 *    I.e. we may launch the test on \b config.h presence via the \a <option>
     66 *    \a -k \a config_h. Also multiple keywords may be given.
     67 *
     68 * \section codetest-results Inspecting results
     69 *
     70 *  The testsuite can be launched with the additional option of \a -d which leaves the
     71 *  directory of the test present even though the test has passed for inspection.
     72 *
     73 *  If a test fails, in whatever way it was launched, will leave in the build directory
     74 *  a folder \b tests/CodeChecks/testsuite.dir/<nr> where \a <nr> is the number of the
     75 *  test (padded maybe with some zeros).
     76 *
     77 *  In the current state tests will fail because one file does not include \b
     78 *  config.h or \b MemDebug.hpp. Hence, check the testsuite's log to get the file
     79 *  name of the culprit at its very bottom.
     80 *
     81 * \section unittest-add Adding new tests
     82 *
     83 *  \attention Name convention of files, (no spaces, use underscore) e.g.
     84 *  \b testsuite-config_h.at
     85 *  - the test script file should be called as follows:
     86 *    -# testsuite-...
     87 *    -# followed by the construct that is tested.
     88 *
     89 *  In order to add a new test, you have to do the following:
     90 *  -# Add a new \b testsuite-....at script to the folder \b tests/CodeChecks
     91 *    (have a look at the present ones and see above for help on the commands
     92 *    recognized by Autotest. \e Mind \e giving it a suitable \e keyword!).
     93 *  -# Add the file to Makefile.am such that the testsuite is re-created when
     94 *    you change the test script.
     95 *  -# Add the file as an \e m4_include directive to testsuite.at.
     96 *
     97 *
     98 * \date 2011-10-31
    4699 *
    47100 */

  • src/documentation/tests/regression-tests.dox

    r19bc74 r750cff  
    2525 * regression tests.
    2626 *
    27  * \section Directory structure
     27 * \section regressiontest-structure Directory structure
    2828 *
    2929 * They are contained in the source folder \b tests/regression. There are
    … …  
    3636 *  named test script one directory level higher.
    3737 *
    38  *  \section Adding a new test
     38 *  \section regressiontest-launch-all Launching all tests
     39 *
     40 *  Launching all regression tests is as simple as:
     41 *  -# Enter the build directory
     42 *  -# There, enter \b tests/regression
     43 *  -# Run
     44 *  \code make check \endcode
     45 *  (at you liberty with option \a -j8 or similar for running the tests in
     46 *  parallel.
     47 *
     48 *  \section regressiontest-launch-some Launching a specific tests
     49 *
     50 *  Launching a single or just some of the tests is only a little bit more
     51 *  complicated. There are two options: either by the test number which however
     52 *  changes when new tests are added, and by keywords.
     53 *
     54 *  Then proceed as follows:
     55 *  -# Enter the build directory
     56 *  -# There, enter \b tests/regression
     57 *  -# Run
     58 *  \code ../../../tests/regression/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
     59 *  where \a <option> is explained in the subsections below and \a <buildpath>
     60 *  is the build path (i.e. the variable \a AUTOTEST_PATH should contain the
     61 *  path to the executable).
     62 *
     63 *  \subsection regressiontest-launch-by-number ... by number
     64 *
     65 *    Tests can be launched by specifying their test number, e.g. then \a <option>
     66 *    might be \a 283 or \a 283-284 or \a 283,285-286 or alike
     67 *
     68 *  \subsection regressiontest-launch-by-keyword .. by keyword
     69 *
     70 *    Tests may as well be launched by some keywords, e.g. each Action has a
     71 *    specific token which is also one of its keyword (see above for the
     72 *    policy). I.e. we may launch the test on fill-void via the \a <option>
     73 *    \a -k \a fill-void. Also multiple keywords may be given.
     74 *
     75 * \section regressiontest-results Inspecting test results
     76 *
     77 *  The testsuite can be launched with the additional option of \a -d which
     78 *  leaves the directory of the test present even though the test has passed
     79 *  for inspection.
     80 *
     81 *  If a test fails, in whatever way it was launched, will leave in the build
     82 *  directory a folder \b tests/regression/testsuite.dir/<nr> where \a <nr> is
     83 *  the number of the test (padded maybe with some zeros).
     84 *
     85 * \section regressiontest-add Adding a new test
     86 *
     87 *  \attention Name convention of files and directories, e.g.
     88 *  \b tests/regression/Parser/Pdb with \b testsuite-parser-pdb-save.at
     89 *  - the test directory should either be called as the token of the Action it
     90 *    tests or a unique and brief description but with no spaces, no dashes,
     91 *    but CamelCase (i.e. Capitalize each new word)
     92 *  - the test script file should be called as follows:
     93 *    -# testsuite-...
     94 *    -# ...each directory (non-capital letters) with a dash...
     95 *    -# ..the name of the test directory...
     96 *    -# a further description of there are multiple test scripts in the
     97 *      test directory.
    3998 *
    4099 *  Adding a new regression tests consists of the following items:
    … …  
    51110 *  testsuite is automatically re-compiled when one of the test files has changed.
    52111 *
    53  *  \section Launching all tests
    54112 *
    55  *  Launching all regression tests is as simple as:
    56  *  -# Enter the build directory
    57  *  -# There, enter \b tests/regression
    58  *  -# Run
    59  *  \code make check \endcode
    60  *  (at you liberty with option \a -j8 or similar for running the tests in parallel.
    61  *
    62  *  \section Launching a specific tests
    63  *
    64  *  Launching a single or just some of the tests is only a little bit more complicated.
    65  *  There are two options: either by the test number which however changes when new
    66  *  tests are added, and by keywords.
    67  *
    68  *  Then proceed as follows:
    69  *  -# Enter the build directory
    70  *  -# There, enter \b tests/regression
    71  *  -# Run
    72  *  \code ../../../tests/regression/testsuite <option> AUTOTEST_PATH="<buildpath>/src" \endcode,
    73  *  where \a <option> is explained in the subsections below and \a <buildpath> is the build
    74  *  path (i.e. the variable \a AUTOTEST_PATH should contain the path to the executable).
    75  *
    76  *  \subsection ... by number
    77  *
    78  *    Tests can be launched by specifying their test number, e.g. then \a <option>
    79  *    might be \a 283 or \a 283-284 or \a 283,285-286 or alike
    80  *
    81  *  \subsection .. by keyword
    82  *
    83  *    Tests may as well be launched by some keywords, e.g. each Action has a specific
    84  *    token which is also one of its keyword (see above for the policy). I.e. we may
    85  *    launch the test on fill-void via the \a <option> \a -k \a fill-void. Also
    86  *    multiple keywords may be given.
    87  *
    88  * \section Inspecting test results
    89  *
    90  *  The testsuite can be launched with the additional option of \a -d which leaves the
    91  *  directory of the test present even though the test has passed for inspection.
    92  *
    93  *  If a test fails, in whatever way it was launched, will leave in the build directory
    94  *  a folder \b tests/regression/testsuite.dir/<nr> where \a <nr> is the number of the
    95  *  test (padded maybe with some zeros).
     113 * \date 2011-10-31
    96114 *
    97115 */

  • src/documentation/tests/tests.dox

    r19bc74 r750cff  
    2525 * testing. Tests are regarded here as a kind of contract. The code itself is
    2626 * just one hand in two hands shaking, the other hand is resembled by the tests
    27  * that checks whether the code does exactly what it's supposed to do. Without
    28  * testing a larger project is impossible because it cannot evolve. With
    29  * increasing size, a project must be refactored
    30  * (http://en.wikipedia.org/wiki/Code_refactoring) such that new code does not
    31  * have to wiggle itself around the same old issues that are present from the
    32  * start. Before one starts refactoring, it must be assured by some means that
    33  * the code before and after behaves the same with respect to its intended
    34  * functionality. These means are the tests.
     27 * that check whether the code does exactly what it's supposed to do. Without
     28 * testing a larger project is impossible because it cannot evolve: The old
     29 * addage and compromises grow and grow. With increasing size, a project must be
     30 * refactored (http://en.wikipedia.org/wiki/Code_refactoring) such that new code
     31 * does not have to wiggle itself around the same old issues that are
     32 * inadvertently and unavoidably present from the start. Before one starts
     33 * refactoring, it must be assured by some means that the code before and after
     34 * behaves the same with respect to its intended functionality. These means are
     35 * the tests.
    3536 *
    36  * Unit tests (http://en.wikipedia.org/wiki/Unit_testing) tests single
    37  * components (e.g. classes), dependencies on other classes are often just
    38  * mimicked via so-called stubs. These test whether a component always behaves
    39  * as desired.
     37 * Unit tests (http://en.wikipedia.org/wiki/Unit_testing) check on single
     38 * components (e.g. classes), dependencies of the components on other classes
     39 * with the test frame are often just mimicked via so-called stubs (sort of
     40 * dummy components that don't calculate or do anything but return an expected
     41 * result suitable for this test only, see http://en.wikipedia.org/wiki/Test_stubs).
     42 * These test whether a component always behaves as desired.
    4043 *
    4144 * Regression test (http://en.wikipedia.org/wiki/Regression_testing) on the other
    … …  
    4548 * has not changed the outcome of older functions.
    4649 *
     50 * \section tests-launch-all Launching all tests
     51 *
    4752 * Note that all tests can be launched via
    4853 * \code make check \endcode
    4954 * in the top build directory.
    5055 *
    51  * \section Policy on launching tests
     56 * \section tests-policy Policy on launching tests
    5257 *
    5358 * Note that the above run of \e all \e tests \e should \e pass for each and
    … …  
    6065 * runs fine and produces a distributable archive.
    6166 *
     67 * \date 2011-10-31
     68 *
    6269 */

  • src/documentation/tests/unit-tests.dox

    r19bc74 r750cff  
    1818 * Unit tests are done via the CppUnit framework (http://cppunit.sourceforge.net/doc/1.8.0/).
    1919 *
    20  * \section Directory structure
     20 * \section unittest-structure Directory structure
    2121 *
    2222 *  Unit tests are always located in a subfolder \b unittests of the component
    … …  
    2424 *  resides in \b src/Parser/unittests.
    2525 *
    26  * \section Adding new tests
    27  *
    28  *  TODO: Documentation - explain how to add tests.
    29  *
    30  * \section Launching all tests
     26 * \section unittest-launch-all Launching all tests
    3127 *
    3228 *  All unit tests can be launched as follows:
    … …  
    3935 * This will run all present unit tests one after the other.
    4036 *
    41  * \section Launching some tests
     37 * \section unittest-launch-some Launching some tests
    4238 *
    4339 *  If only some of the tests should be checked, then they have to be launched by
    … …  
    5652 *  libraries, which have not been installed so far, are found.
    5753 *
    58  * \section Inspecting results
     54 * \section unittest-results Inspecting results
    5955 *
    6056 *  Results of the test are shown during run. An \a Ok(2) indicates that
    6157 *  two tests for the single launched testsuite passed.
    6258 *
     59 * \section unittest-add Adding new tests
     60 *
     61 *  \attention Name convention of files, (no spaces, use CamelCase) e.g.
     62 *  \b AnalysisBondsUnitTest
     63 *  - the unit test module should be called as follows:
     64 *    -# either the name of the component or the module
     65 *    -# followed by UnitTest.
     66 *  - the test class should be called as follows:
     67 *    -# the name of the class it tests
     68 *    -# followed by Test.
     69 *
     70 *  Adding a new test is as easy as this:
     71 *  -# Create a new module for declaration and definition of the unit test
     72 *    in a suitable \b unittests subfolder (see above on policy and naming).
     73 *    Check out one of the present unit tests and rename, but beware of
     74 *    copy&paste errors!
     75 *  -# Add the test to the \b Makefile.am contained in \b unittests.
     76 *
     77 *  If there is not yet a \b unittests folder:
     78 *  -# Create a new \b Makefile.am, check out one of the present ones to get
     79 *    an idea, below is a small list of contained elements. Note that the
     80 *    variable must begin with a unique name as all Makefile.am on unit tests
     81 *    are included into one big Makefile.am in \b src/unittests.
     82 *  -# Add your ...SOURCES and ...HEADERS to TESTSOURCES and TESTHEADERS.
     83 *  -# Add an include directive to \b src/unittests/Makefile.am of this
     84 *    newly created \b Makefile.am.
     85 *
     86 *  What's contained in the \b Makefile.am:
     87 *  -# ...SOURCES and ...HEADERS gathering all source and header files in this
     88 *    \b unittests folder (this is needed for the test program that contains
     89 *    all unit test in one executable).
     90 *  -# ...TESTS gathering all test programs in this \b unittests folder.
     91 *  -# ...TESTS is added to TESTS, check_PROGRAMS, noinst_PROGRAMS such that
     92 *    it is known that they are just tests, programs for \a make \a check and
     93 *    are not to be installed.
     94 *  -# ...LIBS gathers general libs that all of the tests in this \b unittests
     95 *    folder share.
     96 *  -# for each unit test:
     97 *    -# ...SOURCES gathers all source files that are required for the test.
     98 *    -# ...LDADD gathers all libs that are required for compilation.
     99 *
     100 *
     101 * \date 2011-10-31
     102 *
    63103 */
Note: See TracChangeset for help on using the changeset viewer.