rsim / ruby-plsql-spec

Oracle PL/SQL unit testing with Ruby
MIT License
68 stars 25 forks source link

Move code out of spec_helper #29

Open jgebal opened 8 years ago

jgebal commented 8 years ago

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?

javornikolov commented 8 years ago

I'm not very deep into coverage internals yet. How is currently the coverage connection being managed?

jgebal commented 8 years ago

Currently one coverage reporter operates on a single connection alias.

javornikolov commented 8 years ago

How does reporter know which connection alias to work on?

jgebal commented 8 years ago

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

javornikolov commented 8 years ago

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?

jgebal commented 8 years ago

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 .