Open jgebal opened 8 years ago
I'm not very deep into coverage internals yet. How is currently the coverage connection being managed?
Currently one coverage reporter operates on a single connection alias.
How does reporter know which connection alias to work on?
Currently it's a bit dirty. Your local project spec_helper.rb is controlling it. The local project spec_helper is uncovering the ruby-plsql-spec library internals by referencing env parameters used by library and by controlling how the coverage report is done. https://github.com/rsim/ruby-plsql-spec/blob/master/lib/plsql/spec/templates/spec/spec_helper.rb
OK, I see now
PLSQL::Coverage.start(name)
We're iterating over all connections and we're invoking the above for each connection alias name. I guess we can pass a list of connection names if we really need ability to work on a whole list.
So.. What's your idea for refactoring?
Hard to explain. I'll make changes in a branch and share. On 23 Nov 2015 22:13, "Yavor Nikolov" notifications@github.com wrote:
OK, I see now
PLSQL::Coverage.start(name)
We're iterating over all connections and we're invoking the above for each connection alias name. I guess we can pass a list of connection names if we really need ability to work on a whole list.
So.. What's your idea for refactoring?
— Reply to this email directly or view it on GitHub https://github.com/rsim/ruby-plsql-spec/issues/29#issuecomment-159083211 .
If the connection management details would be moved from spec_helper into the library, so that the spec_helper is responsible for managing connections, then the coverage reporter could reference the connection list and perform operations on it.
Any cons of such refactoring?