anchor.diff:    </scoreDirectorFactory>
   ----
   
  -
   This way, the `scoreDrl` will be validated by the ``EasyScoreCalculator``.
  +
  +[NOTE]
  +====
  +This works well to isolate score corruption,
  +but to verify that the score rules implement the real business needs,
  +<<testingScoreConstraints, a unit test with a ScoreVerifier>> is usually better.
  +====
   
   [[scoreCalculationPerformanceTricks]]
   == Score Calculation Performance Tricks
  
positive.code: [[invalidScoreDetection]]
  === Invalid Score Detection
  
  
  Put the `environmentMode` in `FULL_ASSERT` (or ``FAST_ASSERT``) to detect corruption in the <<incrementalScoreCalculation,incremental score calculation>>.
  For more information, <<environmentMode,see the section about `environmentMode`>>.
  However, that will not verify that your score calculator implements your score constraints as your business actually desires.
  
  A piece of incremental score calculator code can be difficult to write and to review.
  Assert its correctness by using a different implementation (for example a ``EasyScoreCalculator``) to do the assertions triggered by the ``environmentMode``.
  Just configure the different implementation as a ``assertionScoreDirectorFactory``:
  
  [source,xml,options="nowrap"]
  ----
  
negative.code:   </scoreDirectorFactory>
  ----
  
  [NOTE]
  ====
  A piece of incremental score calculator code can be difficult to write and to review.
  Assert its correctness by using <<invalidScoreDetection,an ``EasyScoreCalculator`` to do the assertions triggered by the ``environmentMode``>>.
  ====
  
  Optionally, to explain a score with `ScoreDirector.getConstraintMatchTotals()` or to get better output when the `IncrementalScoreCalculator` is corrupted in `FAST_ASSERT` or ``FULL_ASSERT environmentMode``, implement also the `ConstraintMatchAwareIncrementalScoreCalculator` interface:
  
  