Module tests

[allonhadaya]

#34

[allonhadaya]

@fwkz How about that?

[fwkz]

@allonhadaya Please check out new module indexing mechanism in new_loading_mechanism branch. There are few utils function:

• utils.index_modules
• utils.import_exploit
• utils.iter_modules

[allonhadaya]

@fwkz looks good! I'll point out a couple of things.

1. I copied code from RoutersploitInterpreter.module_metadata to grab the __info__ dict. So there's an extra line of duplication now. I'm open to suggestions for improvement.
2. This was true before new_loading_mechanism, but I figure now's a good a time as any to point out that modules that fail the import_exploit call in iter_modules will silently not be tested. If we want to catch those as a module_test failure, we may want a version of iter_modules that just let's the function fail.

[fwkz]

@allonhadaya Thanks for all the hard work. Really appreciate the contribution.

1. We want prevent accidental leakage of exploit's metadata, which contains sensitive information like author name, during the exploit's development process.
   In the sake of keeping the open nature of Python. I have introduced name-mingling mechanism that change name info to ExploitClassName__info_ allowing user to conscious accessing the attribute. Exact same mechanism is already implemented within Python making attribute __foo "private" by changing its name to __ClassName__foo
2. You are right. Definitely we don't want miss something. I will think how to approach that.

[allonhadaya]

@fwkz I'm happy I got to contribute. Feel free to reach out for code reviews / taking a crack at bugs or design issues.