There's more, but it was too large PR. This is the smaller slice, and only the Brakeman::Runner actually gets to take advantage of it immediately.
In this step, we extract a BaseRunner, and a set of shared examples for it, and then rewrite the Brakeman::Runner in terms of that BaseRunner. The BaseRunner does not care about changed_files or file_filter, because it doesn't do any target-selection inherently. It expects to be supplied with a command to run by its subclass, and it runs that command.
In this PR, it doesn't actually look like an improvement - we're adding way more code than we're dropping. But in the next slice we'll make up for it! And even then, the shared examples for BaseRunner are not currently a net gain - we're adding them because they will help any time we need to add a runner like Brakeman::Runner, that doesn't do any relevance-management of targets, and we want adding tools to be as easy as possible.
I did originally intend to keep the tool implementations as isolated as possible, and this reverses that course quite hard. But the prior implementations would actually all still work - new tools can very well still be written that way. Since we're the ones actually implementing a bunch of tools right now though, I decided it was worth it to make it easy for ourselves :-)
There's more, but it was too large PR. This is the smaller slice, and only the Brakeman::Runner actually gets to take advantage of it immediately.
In this step, we extract a BaseRunner, and a set of shared examples for it, and then rewrite the Brakeman::Runner in terms of that BaseRunner. The BaseRunner does not care about
changed_files
orfile_filter
, because it doesn't do any target-selection inherently. It expects to be supplied with a command to run by its subclass, and it runs that command.In this PR, it doesn't actually look like an improvement - we're adding way more code than we're dropping. But in the next slice we'll make up for it! And even then, the shared examples for BaseRunner are not currently a net gain - we're adding them because they will help any time we need to add a runner like Brakeman::Runner, that doesn't do any relevance-management of targets, and we want adding tools to be as easy as possible.
I did originally intend to keep the tool implementations as isolated as possible, and this reverses that course quite hard. But the prior implementations would actually all still work - new tools can very well still be written that way. Since we're the ones actually implementing a bunch of tools right now though, I decided it was worth it to make it easy for ourselves :-)
Slice one of #81