As planned for week 5, the work on proper exposure of API has been completed with the help of thorough guidance by the mentors. Moreover, the modules have been separated among core, cli, tools, and templates. Here is the link to the forked repository working branch. Moreover, the modtool tests for the core modules newmod, add, rename, rm (remove) have been written. Here is the link to the GitHub repository.
Regarding the core modules, the
setup function has been removed and all the arguments get their values in the
__init__ itself. Moreover, proper checks like check on boolean values and improper arguments have been made in a separate
validate function which does not run for arguments passed through CLI because of the checks in the CLI modules themselves. The checks in the CLI modules are same as the ones that existed earlier and have not been moved to the core modules considering the fact that the code should break just after an incorrect argument is passed rather than breaking after all the arguments have been passed for the convenience of the user. Thus, validation for CLI commands does not take place twice. The common parameters get initialized in the
__init__ function of the base module class
Modtool. Moreover, the
ModTool.__init__ does not run completely for commands
info because that is not necessary and also assumes an existing module. So, if
type(self).__name__ in ['ModToolInfo', 'ModToolNewModule'] the code breaks after initializing the arguments. All the imports for module classes or functional definitions have been made relative. Some of the protected members of the modtool classes have been made public for the access of CLI modules and for the simplicity of the user.
The tools like
grc_xml_generator have been moved to a separate directory
tools which is accessible to both
Core modules (the CLI modules utilize some of the
util_functions). The templates,
templates.py, have been moved to a separate
templates directory. The prefix
modtool_ has been removed from the core modules since the helper modules have been moved to a separate directory.
The modtool testing begins with the creation of a new temporary directory in
setUpClass function which runs before the actual testing begins and ends with the deletion of that directory in
tearDownClass function which runs after the entire testing is complete.
Before test for any module, a
setUp function runs the commands for creation of new module in the temporary directory and then adds a block if the previous command ran without raising an exception. After that, the specific tests for the module are run. The tests are skipped if the command necessary for their execution has already failed (like
remove will be skipped if
add fails in the
The tests for the API classes ModToolNewModule, ModToolAdd, ModToolRename, and ModToolRemove have been written. The testing includes the raising of particular exceptions for class instantiation and the assertion for the existence or non-existence of a particular directory or module. For the class
ModToolRemove, there are tests for asserting that the incorrect files are not removed. The reason for the exceptions has been mentioned before most of the
assertRasises statements as a comment.
Moreover, I found a redundant patch of code in the class
ModToolRemove of the
master branch. Here is the link to the pull request.
Tasks for Week 6
- Enhance the tests and add the source in-tree.
- Bug fixes for the API (if any).
- Add a logger and use it instead of print statements.
- Split long functions.
- Make the nested functions without the need of closure as global.
Link to forked repository working branch (core_cli)
Link to the repository containing modtool tests.
Link to the updated GitHub project.