Adding test cases presented in the github issue

Removing JodaTime dependency from Pom.  It had been introduced to
potentially address date/time parsing issues, but had not yet been applied
to the baseline.

Updating test to actually use assertions in execution so that the intended
state is verified.

Adding additional test case content.

Converting ValidationErrorList Test to use Junit4 syntax.

Updating assertions used in ValidationErrorList for more information in
Junit test failure cases.

Breaking the exception cases of the ValidationErrorListTest into separate
test blocks.  Updated to use the ExpectedException Rule.

Corrected wording in implementation error message on null context.
Corrected message in implementation on null ValidationException reference.

Test updates to use class-scope references rather than on a per-test
basis.

Removed method to create ValidationException.  Catch block indicated that
a specific exception had been thrown at one point.  I checked the call
heirarchy and verified that exception is not being explicitly thrown at
this time.

ValidationErrorListTest:
  Removed sysouts
  Cleaned unused imports
  Formatted file (removed tab chars & adjusted indent)

Converting test to Junit4 Syntax.

Commenting out the current test.  Upon inspection, the test is not fulfilling the commented intent.  Instead of validating that the BaseValidationRule throws exceptions, it is only verifying that the test-scope stub implementation throws. Going to keep it around so I can verify I'm fulfilling the intent in the new implementation content before deleting that code

Re-implementing the tests for BaseValidationRule.

** This commit contains a failing test (testWhitelistSetExtendedCharacterSets)**
I do not know how to test utf-16 character sets, but I think it is something that needs to be done.

I have listed a concern with potential side-effects of using ValidationErrorList in the BaseValidationRule.  Refer to testGetValidMultipleExceptionSameContextThrowsRuntimeException for more information.

Initial basic tests for general class functionality.

Adding validations to ensure that DateFormat leniency is being set in accordance with the SecurityConfiguration ACCEPT_LENIENT_DATES value.

Still light in the context that I'm not verifying the value is derived from the SecurityConfiguration, but I am at least checking that the date format is being updated and that the value being applied matches the test-scope settings.

Updating the implementation so the process of generating a String from the parsed date and comparing it with the canonicalized input only happens during the sanitize workflow.  This will allow for the DateFormat contract for leniency and ESAPI's contract for security to remain intact (I think).

In essence, getValid is asking if the configured DateFormat can parse any date out of String being provided. That's completely on the DateFormat instance. If it works then return it, if it doesn't the throw the ValidationException.

On the other hand, sanitize is asking for a safe representation of the String. For that we can add the additional cross check and be more stringent in the criteria. Meaning if the same String that was used to generate the Date cannot be recreated from that date then we don't trust the input.

Tests were updated to reflect this workflow, and the data set used to check 299 in the ValidatorTest has been integrated into DateValidationRuleTest.

Ignoring the explictly fail case in the test.

Adding another sanitize method to the DateValidationRule which accepts the ValidationErrorList in addition to the other parameters.

Updating DefaultValidator to use the new sanitize method and check the error list to verify the returned date before passing it along to the client.  If there are no errors, we're gtg; otherwise, the ValidationError at the first index is rethrown.

Adding tests for new sanitize API method.

Altering method chaining to defer to the getValidDate which uses the ValidationErrorList which now contains the delegation to the DateValidationRule.

Creating a new test class that focuses on testing the DATE API of
DefaultValidator.

This is a wireframe commit.

Successful interception of the DateValidatorRule construction. When
DefaultValidator instantiates a new instance internally, it receives the
test-scope spy.

This will allow us to check that the intended workflow of how the
DefaultValidator delegates to the DateValidatorRule is operating as
expected without needing to re-test the conditions already verified in the
DateValidatorRuleTest.

Working tests to verify happy-path workflow through DefaultValidator Date
API.

Logic update to isValidDate with ValidationErrorList to use the
ValidationErrorList that is passed in with the delegated
DateValidationRule.sanitize call.

Verifying workflow and response from the DateAPI when the
DateValidationRule would result in a ValidationException being thrown.

No functional changes. Mostly updating static imports and references.

Fixing inconsistent indentation in updated method block.

Created a new test for the static ESAPI class which verifies the workflow by which the runtime Validator is derived.

Removed the date validity tests from the ValidatorTest.  All pertinent content has been divided into the BaseValidationRuleTest, DateValidationRuleTest, ValidationErrorListTest, DefaultValidatorDateAPITest, and ESAPIContractAPITests.

The specific conditions have been shifted to be exclusively against the implementation (BaseValidationRuleTest). It is shown that the DefaultValidator uses BaseValidationRule in all date-related checks (DefaultValidatorDateAPITest).  And we know that if the user configures the ESAPI validator property to the DefaultValidator it will resolve at runtime (ESAPIContractAPITests).

Adding Powermock tests that show the lenient setting is derived from the
SecurityConfiguration and is applied to the DateFormat reference both when
a DateValidationRule is constructed, and when the setDateFormat method is
invoked.

I chose to implement this as a unique test since PowermockRunner impacts my ability to see code coverage.