Feature - Implemented Reducing number of warnings: Raw Types (ShowDataCommand)
- Thread starter fredg1
- Start date
@heeheehee I can't... really... add tests... to that one...
All of the parts that were changed base themselves off of KoLConstants.availableSkills, which is an empty list during tests, and can't be modified manually...
Other than that, the file's still up to date ( ._.)
All of the parts that were changed base themselves off of KoLConstants.availableSkills, which is an empty list during tests, and can't be modified manually...
Other than that, the file's still up to date ( ._.)
I'm not in a position to try this out right now but we could probably Mock availableSkills so that it returned something in a test environment. It also looks like you could make a UseSkillRequest and the use KoLConstants.availableSkills.add( skill ) as part of the setup for a test. Not sure of the visibility but there used to be a way to mark a private or package field or method as visible for testing.
Writing such a test might not be the best use of someone's time but it should be possible when we want it badly enough.
One option: add `test skills add <foo>` to TestCommand (calling out to KoLCharacter.addAvailableSkill, for instance), and then write a couple of scripts for CustomScriptTest.
e.g.
->
and
->
It'll likely come in handy elsewhere, and there's already clear precedent per inventory / stats manipulation.
e.g.
Code:
have_skill Lasagna Bandages
test skills add Lasagna Bandages
have_skill Lasagna Bandages
Code:
Returned: false
You now know Lasagna Bandages.
Returned: true
Code:
test skills add Lasagna Bandages
test skills add Disco Nap
skills disco
Code:
You now know Lasagna Bandages.
You now know Disco Nap.
Disco Nap (8 mp)It'll likely come in handy elsewhere, and there's already clear precedent per inventory / stats manipulation.
@heeheehee
Adds the test skill add <id> and test skill remove <id> commands.
The tests add skills, checks the output of the skills command, then with a filter, than removes the added skills (and makes sure the skill list is empty).
That last part is important. KoLConstants.availableSkills being a static field, not reverting the addition of the skills would have their presence be kept in all the subsequent tests.
Adds the test skill add <id> and test skill remove <id> commands.
The tests add skills, checks the output of the skills command, then with a filter, than removes the added skills (and makes sure the skill list is empty).
That last part is important. KoLConstants.availableSkills being a static field, not reverting the addition of the skills would have their presence be kept in all the subsequent tests.
The usual solution to inadvertent globalization with tests is to use @before and/or @after to set things to a known state before and after a test. The implementation of CustomScriptTest as a data driven test makes this a little awkward but perhaps this is the time to do so? That leaves it up to script authors to make sure they "revert" their global changes in code and not the script. Not that I expect there to be one, but if there is any inadvertent dependency on the order the scripts are executed this would eliminate that as well.