The commands provided by the interactive interpreter were separated as "plugins" in the previous part of this series. Currently they are totally separate from the interpreter part. I will look into hooking them up with the interpreter in this part, at least on mock level. :)
Mocking the Interpreter to Accept Commands
In my earlier implementation the interpreter contained the needed commands. This is not a particularly mock friendly way to handle it. Considering the commands will be provided from some source (ie. from plugin loader in this case), it makes sense to provide them to the interpreter on its construction phase or to provide a method to load commands into it. I will mock the former case.
For now there are two separate cases to mock based on the execute method signature. As you might still remember, it was defined so that the parameter provided to the method depends on what the command actually happens to use (ie. it may "commands" or "variables" currently).
Here's the test I came up with for this case:
test_interpreter.py:
Essentially the test makes sure that the methods get executed with proper parameters and that those parameters have valid values in them. Additionally there's an assert for "matches" method. It might make sense to separate that case into a test of its own but that will do for now.
Here's my implementation so far:
interpreter.py:
As it's probably clear, the current tests enforce that the interpreter has to be able to work with just one command. It's still missing the case for multiple ones. I will add that one next. Note that I restructured tests by introducing an abstract base class for all of my test classes. Here's test_interpreter.py as a whole:
And implementation:
interpreter.py:
Summary
Cool! Now we are missing just the part that actually loads the plugins (PluginLoader) and the part that feeds them to the interpreter (Application). I will look into PluginLoader in the next part of the series. You may find the source code of this part here.