Project

General

Profile

Feature #9030

Feature #10237: Refactor and clean up the automated test suite

Encapsulate our test suite helper functions inside a module

Added by anonym almost 5 years ago. Updated about 3 years ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Test suite
Target version:
-
Start date:
03/07/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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 #8966 (see especially #8966#note-26), we should do this, or something similar (e.g. put them in a class).

Associated revisions

Revision e35abea0 (diff)
Added by anonym about 3 years ago

Encapsulate exec_helper's class.

... to not "pollute" the global namespace with all our helpers. This is
an example of how we can work towards #9030.

Refs: #9030

History

#1 Updated by anonym almost 5 years ago

[...] 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 almost 5 years ago

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.

#4 Updated by anonym about 4 years ago

  • Parent task set to #10237

#5 Updated by anonym about 4 years ago

  • Target version changed from Tails_1.7 to Tails_1.8

#6 Updated by intrigeri about 4 years ago

  • Target version changed from Tails_1.8 to Tails_2.2

Postponing to after January, since times will be a bit crazy until then.

#7 Updated by anonym almost 4 years ago

  • Target version changed from Tails_2.2 to Tails_2.5

#8 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.5 to Tails_2.7

#9 Updated by anonym about 3 years ago

  • Target version deleted (Tails_2.7)

Also available in: Atom PDF