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?



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?



Regards

Stefan

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?

--- 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.

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