Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen_developers] Unit test questions

Expand Messages
  • James Dempsey
    Hi Stefan, On 23/02/2013 12:50 AM Stefan Radermacher wrote ... * code/src/test - general tests that may have a wide range of dependencies per test. This is our
    Message 1 of 4 , Feb 22, 2013
    • 0 Attachment
      Hi Stefan,

      On 23/02/2013 12:50 AM Stefan Radermacher wrote
      Just two quick questions
      
      1) What is the difference between the various unit test categories we
      have: code/src/test vs. code/src/utest vs. code/src/itest?
      
      • code/src/test - general tests that may have a wide range of dependencies per test. This is our original test folder
      • code/src/utest - Quick single function unit tests with low dependencies. These are the ones that get run on the default ant build. Any tests here should not need the plugin jars loaded or the spring container initiated. They should also be able to be run in a single JVM (so not have side effects).
      • code/src/itest - Integration tests - these are tests that verify the end to end behaviour of areas of the code, particularly the CDOM code. They normally require the spring container and the plugins to be loaded. As a result they run in a separate JVM per test and are slower than other tests.
      • code/src/testcommon - This is a set of dependencies which may be used in any other test. It is used because maven will not see files in one tests folder/category when running the tests from a different folder.
      2) Can I create a simple test case to calculate a character's CR without
      having to provide a full pcg file? I.e. create a character, set race and
      levels via code?
      
      Yes, you will want to create a new test class that extends AbstractCharacterTestCase. See pcgen.core.PlayerCharacterSpellTest for an example. You will most likely want to put this sort of test in code/src/test.

      Cheers,
      James.
    • thpr
      ... In general these would be tests that are checking one class (though it may rely on others as a side effect). As a result, these tests are generally lined
      Message 2 of 4 , Feb 22, 2013
      • 0 Attachment
        --- In pcgen_developers@yahoogroups.com, James Dempsey <jdempsey@...> wrote:
        > * code/src/utest - Quick single function unit tests with low
        > dependencies. These are the ones that get run on the default ant
        > build. Any tests here should not need the plugin jars loaded or the
        > spring container initiated. They should also be able to be run in a
        > single JVM (so not have side effects).

        In general these would be tests that are checking one class (though it may rely on others as a side effect). As a result, these tests are generally lined up in the package with the class they are testing. Alternatively, they are in a package identifying the interface of the class being tested (e.g. selectionactor) [The separate unit testing per interface allows us to better extend base classes to share test code]

        > * code/src/itest - Integration tests - these are tests that verify the
        > end to end behaviour of areas of the code, particularly the CDOM
        > code. They normally require the spring container and the plugins to
        > be loaded. As a result they run in a separate JVM per test and are
        > slower than other tests.

        In general, these are testing integration of entire subsystems or cross-subsystem behavior. The package name thus often an identification of the subsystems being tested together (e.g. tokenmodel tests links from parsing the tokens to loading the data into the in-memory character model.)

        > > 2) Can I create a simple test case to calculate a character's CR without
        > > having to provide a full pcg file? I.e. create a character, set race and
        > > levels via code?
        >
        > Yes, you will want to create a new test class that extends
        > AbstractCharacterTestCase. See pcgen.core.PlayerCharacterSpellTest for
        > an example. You will most likely want to put this sort of test in
        > code/src/test.

        Such a test definitely belongs in code/src/test :)

        Another alternative is to directly inject the required facts and test the output. This depends on what you are trying to achieve in a given test... but if you really want the full object in to output token type test, then what James describes is probably best.

        The smallest test is if you are attempting to check just the calculation of CRFacet. That has not yet been done and would be placed in /utest/pcgen.cdom.facet.analysis.CRFacetTest.java

        The integration test would for /itest/ should eventually be something like a modeloutput package, and would be the appropriate place for testing something like CR from the various possible change locations (Race, Template, BONUS, etc.) through to the output token.

        (Note there is probably never a tokenmodel test for something like CR since it is already very basic in being a number/formula. So the token tests in the utest directory already perform what would be the equivalent of the tokenmodel tests for CR. If you look closely, the tokenmodel tests that are there are all tokens that perform an "allow" or "grant" of an object, not just act as a holder of a "fact" (CR, Hands, etc.). All of the "facts" that interact will eventually need something like the modelanalysis itest. Note also that the "allow", "grant" and "fact" statements are the keywords I'm using here: http://wiki.pcgen.org/LST_Token_Information which is the page I'm using to help track my development of such unit tests.)

        TP.
      • Stefan Radermacher
        Thanks, Tom and James, that was very helpful. I was able to create a test class in code/src/test that goes through various character setups and tests the
        Message 3 of 4 , Feb 22, 2013
        • 0 Attachment
          Thanks, Tom and James, that was very helpful. I was able to create a
          test class in code/src/test that goes through various character setups
          and tests the calculated CRs as well as the loader code for the involved
          tags.

          I'm still getting used to unit tests. Very nice.

          Regards
          Stefan
        Your message has been successfully submitted and would be delivered to recipients shortly.