Attester evolution #35

piuccio opened this Issue Jun 14, 2013 · 3 comments


None yet
1 participant

piuccio commented Jun 14, 2013

This is to track the evolution of attester into a modular system.

The base need is to let user extend attester behavior without modifying the core structure. A source of inspiration is grunt and its plugin system.

extensibility points

  • configuration the user should be able to load any possible configuration data, even information that are not handled directly by attester. For example the configuration for a Selenium driver. Moreover plugins should have access to the configuration.
  • test-type it should be possible to load external plugins to generate test tasks. Attester comes with two test types aria-templates and mocha. More might be needed in the future. Test types should have access to attester's configuration, utilities and middlewares.
  • output so far attester generates output in the console and can be configured to generate an XML report file. In order to integrate this tool with other services (CI) it's paramount to let the user choose or create different type of reports. Reports should not just craft output files, but could be more advanced
  • runner attester core functionality should only contain the server. All the logic that launches external browsers (for now only phantom) should be external. It should also be possible to create plugins for launching remote browsers, for instance selenium grid, sauce labs or browser stack.

piuccio commented Jun 14, 2013

proposed architecture

The main idea is to shift from a command line utility to a generic module.

Similar to grunt we can have two packages attester and attester-cli. The command line interface would

  • parse command line parameters
  • load attester module
  • start a campaign
  • start phantom if necessary

Attester module will have the following API (stealing from grunt)

  • initConfig to initialize the module configuration
  • registerTask to add a task function (plugin)
  • loadTask to load tasks from the file system
  • loadNpmTask to load tasks from an npm module
  • run to start the module

It'll be an EventEmitter raising at least the following events

  • configInit raised before accessing the configuration. This allows plugin to modify the configuration before it is used. Examples are the templating systems for configuration, or loading configuration parameters from external files (package.json). Event listeners receive an object that allows to read and modify the configuration.
  • campaingCreate raised when the campaign is being created. This allows plugins to create tasks from test files. Event listeners receive an object on which they can register new task. Task registration must be asynchronous because some test types might want to read files from the disk before generating a task.
  • campaignCreated raised after the campaign has been created.
  • campaignAvailable raised when a new campaign is available on the server (corresponds to the old serverAttached event).
  • campaignFinished raised when the campaign is completely executed from the server. This event should contain the test result.
  • serverCreate raised when the server is being create. Similarly to campaingCreate this allows plugins to connect middlewares to be used for sending tests or other purposes.
  • serverCreated raised after the server has been created and is listening.
  • serverClosed raised when the server has been shut down

Regarding th extensibility on the output, it might be a good idea to have a two-tier system. What is now the json logger is the first layer, a module that receives any possible update from the slaves and from attester itself.
Output plugins might benefit from a filtered and structured output, things like

  • slaveConnect
  • campaignStarted
  • taskStarted
  • taskEnded (with information on status, duration, slave that run it and whatever might be useful)
  • campaignEnded

piuccio commented Jun 14, 2013

usage example

From a user perspective there shouldn't be any difference in the command line nor in the maven plugin.
If needed for more complex behaviors she might write an attester file instead of a plain configuration object.

attesterFile.js might look like this

var attester = require("attester");

    // directly a json file
// an alternative could be
attester.initConfig("a file path"); // to read directly from the file system

// If a plugin requires configuration it should be in the configuration file / object passed to initConfig


piuccio commented Nov 13, 2014

attester now have even plugins, I guess this can be closed

piuccio closed this Nov 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment