Feature #9030: Encapsulate our test suite helper functions inside a module

Feature #9030

Encapsulate our test suite helper functions inside a module

Added by anonym 2015-03-07 00:59:06 . Updated 2016-10-19 14:05:11 .

Status:

Confirmed

Priority:

Normal

Assignee:

anonym

Category:

Test suite

Target version:

Start date:

2015-03-07

Due date:

% Done:

Feature Branch:

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Deliverable for:

Description

Background:

Given how Ruby works, all def:s at the “lowest” level (i.e. outside any class or method) actually get added into the Object class (which all other classes inherit), so we actually add goodies like wait_until_tor_is_working to Object, so "some string".wait_until_tor_is_working is a perfectly fine way to call it in our test suite. :) I suppose the right way would be to encapsulate such functions in a module like this:

module Helpers
  def self.wait_until_tor_is_working
  [...]
  end
end

and then call them as Helpers.wait_until_tor_is_working. The same problem exists for the helper functions we define in the various step definition files (like configured_pidgin_accounts in pidgin.rb), so perhaps all helpers should also be added into the Helpers module at the top of each step definitions file (keeping them in the affected file is imho good for readability); multiple module statements for the same module name will just keep on building up the same one.

Hence, if we care about not polluting Object and risk more collisions of the kind we experienced in ~~Feature #8966~~ (see especially ~~Feature #8966#note-26~~), we should do this, or something similar (e.g. put them in a class).

Subtasks

History

#1 Updated by anonym 2015-03-07 03:00:43

> […] perhaps all helpers should also be added into the Helpers module at the top of each step definitions file (keeping them in the affected file is imho good for readability)

And of course, if a helper is used in multiple step definition files we move it into misc_helpers.rb, much like how we (try) to put step definitions that are used in multiple files into common_steps.rb. Ruby has no scope based on file, so it’s irrelevant from Ruby’s perspective, at least as long as there are no name collisions, then that last one loaded wins.

We could also consider moving everything in misc_helpers.rb into common_steps.rb, but some of the stuff in there are no only used by the step definition files; e.g. the assert* functions we include there are used all over the place, convert_to_* are used in both {storage,vm}_helper.rb and some step definitions, cmd_helper is used in config.rb and some step definitions, etc.

Organizing this neatly without over-engineering it is a problem. I don’t think we want excessive amounts of modules and sub-modules, so we have to write tediously long stuff like Helpers::Storage::Units.convert_to_MiB. I should check how it’s done in other cucumber test suites.

#2 Updated by intrigeri 2015-03-07 09:36:10

> Organizing this neatly without over-engineering it is a problem. I don’t think we want excessive amounts of modules and sub-modules, so we have to write tediously long stuff like Helpers::Storage::Units.convert_to_MiB. I should check how it’s done in other cucumber test suites.

I like the general idea. I agree we shouldn’t split it into too many modules. Now, if some amount of splitting feels like it would make things leaner, let’s do it. Sometimes namespacing allows factoring repeated substrings out of function names, e.g. (crappy first example that pops up to my mind) Helpers::Tor::wait_until_is_ready so it doesn’t necessarily make the resulting “absolute” function name much longer.