Unit tests are placed in package pyherc.test.unit Any module that is
named as “test_*” will be inspected automatically by Nose when it is gathering
tests to run. It will search for classes named “Test*” and methods named
“test_*”.

Following code is simple test that creates EffectHandle object and tries to
add it into EffectsCollection object. Then it verifies that it actually was
added there.

Interesting parts of the test are especially the usage of EffectHandleBuilder
to create the EffectHandle object and the customer has_effect_handle matcher.

Builders are used because they make setting up objects easy, especially when
dealing with very complex objects (Character for example). They are placed
at pyherc.test.builders module.

Custom matchers are used because they make dealing with verification somewhat
cleaner. If the internal implementation of class changes, we need to only
change how builders construct it and how matchers match it and tests should not
need any modifications. Custom matchers can be found at
pyherc.test.matchers module.

Three macros are provided to help reduce boilerplate from tests: background,
fact and with-background. Background is used to create setup function.
It can return one or more symbols for tests:

The example code creates background called weapons and initializes it with
item and character symbols. In addition, set-action-factory is
called for side effect.

Facts are executable tests, that can be standalone, or use previously defined
background. When using a background, a list of symbols to retrieved is given
to with-background macro. This will generate a call to background and
retrieve specified symbols to current scope:

Cutesy is an internal domain specific language. Basically, it’s just a
collection of functions that can be used to contruct nice looking tests. Theory
is that these easy to read tests can be used to communicate what the system
is supposed to be doing on a high level, without making things complicated
with all the technical details.

Here’s an example, how to test that getting hit will cause hit points to go
down.

Doctest tests are written inside of .rst documents that are used to generate
documentation (including this one you are currently reading). These documents
are placed in doc/api/source folder and folders inside it.

Tests with behave are placed under directory behave/features. They consists of
two parts: feature-file specifying one or more test scenarios and python
implementation of steps in feature-files.

The earlier Cutesy example can be translated to behave as follows:

Feature: Combat
as an character
in order to kill enemies
I want to damage my enemies
Scenario: hit in unarmed combat
Given Pete is Adventurer
And Uglak is Goblin
And Uglak is standing in room
And Pete is standing next to Uglak
When Uglak hits Pete
Then Pete should have less hitpoints

Each of the steps need to be defined as Python code:

@given(u'{character_name} is Adventurer')defimpl(context,character_name):ifnothasattr(context,'characters'):context.characters=[]new_character=Adventurer()new_character.name=character_namecontext.characters.append(new_character)

It is advisable not to reimplement all the logic in behave tests, but reuse
existing functionality from Cutesy. This makes tests both faster to write and
easier to maintain. For more information on using behave, have a look at their
online tutorial.