Feature Envy when Mixing in Modules

Question

I'm currently writing a very simple start to a test tool. The idea is that you can have classes that include my "Testable" module. For example:

class Veilus
  include Testable
end

site = Veilus.new

The Testable module has the following:

module Testable
  module_function

  def included(caller)
    caller.extend Testable::Interface::Page::Attribute
    caller.__send__ :include, Testable::Interface::Page
  end
end

When Reek checks out this file, it returns:

FeatureEnvy: Testable#included refers to 'caller'
more than self (maybe move it to another class?)

But isn't that one of the points of the included method?

I realize that I can turn this aspect of Reek checking off but I'm curious exactly how I would go about following its advice here? The class, in this case, is not something I'll know about a head of time. Classes that other people write will include my module.

Again, I know I can turn off the check but it seems like I might want the check in other contexts. So then I started to wonder if perhaps I'm doing the "mixin" approach wrong and that's what Reek is pointing out.

Answer 1

I found one way to "handle" this, which is essentially to just use self to reference the included call. So, for example, I could do this:

module Testable
  def self.included(caller)
    caller.extend Testable::Interface::Page::Attribute
    caller.__send__ :include, Testable::Interface::Page
  end
end

What I did was change my above code such that the call to module_function is no longer used. (Although that does run afoul of some other style guide rules.) Then I just used self. in front of the included message.

When I do that, the FeatureEnvy warning no longer occurs. This seems like a pretty weak way for the FeatureEnvy condition to be flagged, to be honest.

This, along with various other issues, has convinced me not to use Reek and just stick with Rubocop. (I realize they are, in many cases, looking at very different things.) I would not advocate this approach for enterprise-type development but in terms of writing test tools, I find you actually do a lot of "clever" things that checkers like Reek just don't like.