Re: [pcgen_developers] Unit test questions
- 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
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.
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 firstname.lastname@example.org, James Dempsey <jdempsey@...> wrote:
> * code/src/utest - Quick single function unit tests with lowIn 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]
> 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 theIn 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.)
> 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.
> > 2) Can I create a simple test case to calculate a character's CR withoutSuch a test definitely belongs in code/src/test :)
> > 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
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.)
- 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
I'm still getting used to unit tests. Very nice.