Closed telaviv closed 9 years ago
I was under the impression that you'd write some core code that could be shared by both plugins and that it would be developed as a separate package from testify's core. We've made the mistake in the past of coupling the plugins too tightly with the core code when most of the consumers don't even use them. I'd advise creating a separate repository and developing your plugin in there.
@asottile The problem is that the shared code would be exactly one line long:
imp.load_source('__startup.module', startup_module)
for both the pytest + testify plugins, the vast majority of the code, is tests + making that one line work with the plugin hooks provided by the framework.
Either way, I don't think this code belongs in Yelp/Testify and probably instead belongs in something like testify_my_plugin_name
I've found that pytest has a -p option, which loads a named plugin (really just imports a named module) before tests start. It wouldn't be so disagreeable to add to testify add long as we match the pytest design, and it should be pretty simple to implement.
--phone is hard. On Oct 9, 2014 5:30 PM, "Shawn Krisman" notifications@github.com wrote:
@asottile https://github.com/asottile The problem is that the shared could would be exactly one line long:
imp.load_source('__startup.module', startup_module)
for both the pytest + testify plugins, the vast majority of the code, is tests + making that one line work with the plugin hooks provided by the framework.
— Reply to this email directly or view it on GitHub https://github.com/Yelp/Testify/pull/292#issuecomment-58598279.
testify already has a env variable called TEST_FILE_NAME that does just about the same thing as -p. I've decided to go that direction instead.
This is an almost identical copy of a plugin I wrote for pytest. The idea is that if you need the side effects of a module to be run by importing, you simply pass --startup-module and the name file to import. This is really important for things like patching.
Oftentimes you will end up in a situation where patching a module BEFORE it is imported has a different behavior than AFTER you imported it. If you need to guarantee that patching happens BEFORE any test module is imported, then this plugin is the only way to accomplish it.