Auto-tools/Projects/CrossWeave/Test Format: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
The test files used by CrossWeave are all written in JSON; these drive the test.  There is no scripting required to create test cases.
== Overview ==


The general format of a CrossWeave test is as follows, shown without the JSON formatting characters:
The test files used by CrossWeave are all written in a YAML-like syntax; these drive the test.  There is no scripting required to create test cases.


  setup
The general format of a CrossWeave test is as follows:
   profiles: [profile1, profile2, ..., profile-n]
 
  setup:
   profiles:  
    * profile1
    * profile2
    * profile-n
  asset-list-1
  asset-list-1
  ...
  ...
Line 10: Line 15:
  phase-1:
  phase-1:
   profile: profile1
   profile: profile1
   actions: [action1, action2, ..., action-n]
   actions:
    * action1
    * action2
    * action-n
  phase-2:
  phase-2:
   profile: profile2
   profile: profile2
   actions: [action1, action2, ..., action-n]
   actions:
    * action1
    * action2
    * action-n
  ...
  ...
  phase-n:
  phase-n:
   profile: profile1
   profile: profile2
   actions: [action1, action2, ..., action-n]
   actions:
    * action1
    * action2
    * action-n


== The Setup Block ==
== The Setup Block ==
Line 23: Line 37:
The setup block just lists the profiles that will be used during the test.  CrossWeave creates these profiles before Firefox is launched.  The profiles can be given any names.  A complete setup block might look like:
The setup block just lists the profiles that will be used during the test.  CrossWeave creates these profiles before Firefox is launched.  The profiles can be given any names.  A complete setup block might look like:


  "setup": {
setup:
    "profiles": ["profile1", "profileGesundheit"]
  profiles:
  },
    * profile1
    * profile2


== Asset Lists ==
== Asset Lists ==
Line 40: Line 55:
As a simple example, without explaining the format, a short list of bookmarks might look like this:
As a simple example, without explaining the format, a short list of bookmarks might look like this:


  "bookmark-list-1": {
bookmark-list-1:
    "menu": [
  menu:
      { "uri": "http://www.apple.com/iphone/", "title": "iPhone" },
    * uri: http://www.yahoo.com
      { "uri": "http://bugzilla.mozilla.org/show_bug.cgi?id=%s", "title": "Bugzilla", "keyword": "bugzilla" },
      title: testing Yahoo
      { "separator": true },
    * uri: http://www.cnn.com
      { "uri": "http://www.mozilla.com" }
      description: This is a description of the site a at www.cnn.com
    ]
    * seperator: true
  },
    * livemark: Livemark1
      feedUri: http://rss.wunderground.com/blog/JeffMasters/rss.xml
      siteUri: http://www.wunderground.com/blog/JeffMasters/show.html


== Phase Blocks ==
== Phase Blocks ==
Line 59: Line 76:
Let's look at a simple phase block:
Let's look at a simple phase block:


  "phase1": {
phase1:
    "profile": "profile1",
  profile: profile1
    "actions": [
  actions:
      { "add": { "bookmarks": "bookmark-list-1" },
    * add:
      { "sync": "all", "wipe-server": true }
        bookmarks: bookmark-list-1
    ]
    * sync: all
  },
      wipe-server: true


This will cause CrossWeave to launch Firefox with the profile '''profile1''', add all the bookmarks specified in '''bookmark-list-1''', then do a full sync to Weave with the '''wipe-server''' setting, which causes any existing data for the Weave account being used to be wiped, before data from the local client is synced to it.
This will cause CrossWeave to launch Firefox with the profile '''profile1''', add all the bookmarks specified in '''bookmark-list-1''', then do a full sync to Weave with the '''wipe-server''' setting, which causes any existing data for the Weave account being used to be wiped, before data from the local client is synced to it.
Line 71: Line 88:
This should have the effect of syncing all the bookmarks we just added to our Weave account.  We could test this using a second phase:
This should have the effect of syncing all the bookmarks we just added to our Weave account.  We could test this using a second phase:


  "phase2": {
phase2:
    "profile": "profileGesundheit",
  profile: profile2
    "actions": [
  actions:
      { "sync": "all" },
    * sync: all
      { "verify": { "bookmarks": "bookmark-list-1" }
    * verify:
    ]
        bookmarks: bookmark-list-1
  },


This will cause CrossWeave to launch Firefox with a different profile, which knows nothing about the bookmarks we added to '''profile1'''.  It syncs with Weave, which should pull all of our bookmarks to the local client.  It then verifies that all the bookmarks in '''bookmark-list-1''' are indeed present.
This will cause CrossWeave to launch Firefox with a different profile, which knows nothing about the bookmarks we added to '''profile1'''.  It syncs with Weave, which should pull all of our bookmarks to the local client.  It then verifies that all the bookmarks in '''bookmark-list-1''' are indeed present.


=== Phase Actions ===
=== Phase Actions ===
This is a list of valid actions:
* '''sync''': activates a Weave sync
** valid values: 
*** "all", syncs everything
*** others not yet implemented (e.g., "bookmarks-only")
** additional optional keys:
*** "wipe-server": true, causes all data on the Weave server to be wiped before the sync takes place
*** "wipe-client": true, causes all data on the client to be wiped before the sync takes place
*** "reset-client": true, causes the client to be reset before the sync (what does this mean?)
* '''private-browsing''': sets private browsing mode
** valid values: true or false
* '''add''': populates the browser with the given assets
* '''delete''': deletes the given assets from the browser
* '''modify''': performs the specified modifications on assets which already exist in the browser
* '''verify''': verifies that the given assets exist in the browser
* '''verify-not''': verifies that the given assets do not exist in the browser
For all actions other than '''sync''', the action's value is an object with one or more key-value pairs denoting valid asset lists.  Each key in this object is one of: 
* '''bookmarks'''
* '''passwords'''
* '''history'''
* '''tabs''' (not yet implemented)
* '''formdata''' (not yet implemented)
* '''prefs''' (not yet implemented)
and each key's value is the name of the relevant asset list in the test file.


== Putting It All Together ==
== Putting It All Together ==
Line 87: Line 130:
Combining the test case blocks above into one file, we now have a complete test case:
Combining the test case blocks above into one file, we now have a complete test case:


  {
setup:
    "setup": {
  profiles:
      "profiles": ["profile1", "profileGesundheit"]
    * profile1
    },
    * profile2
    "bookmark-list-1": {
bookmark-list-1:
      "menu": [
  menu:
        { "uri": "http://www.apple.com/iphone/", "title": "iPhone" },
    * uri: http://www.yahoo.com
        { "uri": "http://bugzilla.mozilla.org/show_bug.cgi?id=%s", "title": "Bugzilla", "keyword": "bugzilla" },
      title: testing Yahoo
        { "separator": true },
    * uri: http://www.cnn.com
        { "uri": "http://www.mozilla.com" }
      description: This is a description of the site a at www.cnn.com
      ]
    * seperator: true
    },
    * livemark: Livemark1
    "phase1": {
      feedUri: http://rss.wunderground.com/blog/JeffMasters/rss.xml
      "profile": "profile1",
      siteUri: http://www.wunderground.com/blog/JeffMasters/show.html
      "actions": [
phase1:
        { "add": { "bookmarks": "bookmark-list-1" },
  profile: profile1
        { "sync": "all", "wipe-server": true }
  actions:
      ]
    * add:
    },
        bookmarks: bookmark-list-1
    "phase2": {
    * sync: all
      "profile": "profileGesundheit",
      wipe-server: true
      "actions": [
phase2:
        { "sync": "all" },
  profile: profile2
        { "verify": { "bookmarks": "bookmark-list-1" }
  actions:
      ]
    * sync: all
    }
    * verify:
  }
        bookmarks: bookmark-list-1
 
The test file must be valid JSON; if you get errors from CrossWeave about JSON decoding, you can copy and paste your test into http://jsonlint.com, which can be helpful for finding JSON errors.

Latest revision as of 20:30, 24 September 2010

Overview

The test files used by CrossWeave are all written in a YAML-like syntax; these drive the test. There is no scripting required to create test cases.

The general format of a CrossWeave test is as follows:

setup:
  profiles: 
    * profile1
    * profile2
    * profile-n
asset-list-1
...
asset-list-n
phase-1:
  profile: profile1
  actions:
    * action1
    * action2
    * action-n
phase-2:
  profile: profile2
  actions:
    * action1
    * action2
    * action-n
...
phase-n:
  profile: profile2
  actions:
    * action1
    * action2
    * action-n

The Setup Block

The setup block just lists the profiles that will be used during the test. CrossWeave creates these profiles before Firefox is launched. The profiles can be given any names. A complete setup block might look like:

setup:
  profiles:
    * profile1
    * profile2

Asset Lists

A test file will contain one or more asset lists, which are lists of bookmarks, passwords, or other types of browser data that are relevant to Weave. The format of these asset lists vary depending on asset type, and are explained in detail at these links:

As a simple example, without explaining the format, a short list of bookmarks might look like this:

bookmark-list-1:
  menu:
    * uri: http://www.yahoo.com
      title: testing Yahoo
    * uri: http://www.cnn.com
      description: This is a description of the site a at www.cnn.com
    * seperator: true
    * livemark: Livemark1
      feedUri: http://rss.wunderground.com/blog/JeffMasters/rss.xml
      siteUri: http://www.wunderground.com/blog/JeffMasters/show.html

Phase Blocks

The phase blocks are where the action happens! They tell CrossWeave what to do. Each phase block contains the name of a profile, and a list of actions. CrossWeave iterates through the phase blocks in alphanumeric order, and for each phase, it does the following:

  1. Launches Firefox with the specified profile
  2. Performs the specified actions
  3. Determines if the phase passed or failed; if it passed, it continues to the next phase block and repeats the process

Let's look at a simple phase block:

phase1:
  profile: profile1
  actions:
    * add:
        bookmarks: bookmark-list-1
    * sync: all
      wipe-server: true

This will cause CrossWeave to launch Firefox with the profile profile1, add all the bookmarks specified in bookmark-list-1, then do a full sync to Weave with the wipe-server setting, which causes any existing data for the Weave account being used to be wiped, before data from the local client is synced to it.

This should have the effect of syncing all the bookmarks we just added to our Weave account. We could test this using a second phase:

phase2:
  profile: profile2
  actions:
    * sync: all
    * verify:
        bookmarks: bookmark-list-1

This will cause CrossWeave to launch Firefox with a different profile, which knows nothing about the bookmarks we added to profile1. It syncs with Weave, which should pull all of our bookmarks to the local client. It then verifies that all the bookmarks in bookmark-list-1 are indeed present.

Phase Actions

This is a list of valid actions:

  • sync: activates a Weave sync
    • valid values:
      • "all", syncs everything
      • others not yet implemented (e.g., "bookmarks-only")
    • additional optional keys:
      • "wipe-server": true, causes all data on the Weave server to be wiped before the sync takes place
      • "wipe-client": true, causes all data on the client to be wiped before the sync takes place
      • "reset-client": true, causes the client to be reset before the sync (what does this mean?)
  • private-browsing: sets private browsing mode
    • valid values: true or false
  • add: populates the browser with the given assets
  • delete: deletes the given assets from the browser
  • modify: performs the specified modifications on assets which already exist in the browser
  • verify: verifies that the given assets exist in the browser
  • verify-not: verifies that the given assets do not exist in the browser

For all actions other than sync, the action's value is an object with one or more key-value pairs denoting valid asset lists. Each key in this object is one of:

  • bookmarks
  • passwords
  • history
  • tabs (not yet implemented)
  • formdata (not yet implemented)
  • prefs (not yet implemented)

and each key's value is the name of the relevant asset list in the test file.

Putting It All Together

Combining the test case blocks above into one file, we now have a complete test case:

setup:
  profiles:
    * profile1
    * profile2
bookmark-list-1:
  menu:
    * uri: http://www.yahoo.com
      title: testing Yahoo
    * uri: http://www.cnn.com
      description: This is a description of the site a at www.cnn.com
    * seperator: true
    * livemark: Livemark1
      feedUri: http://rss.wunderground.com/blog/JeffMasters/rss.xml
      siteUri: http://www.wunderground.com/blog/JeffMasters/show.html
phase1:
  profile: profile1
  actions:
    * add:
        bookmarks: bookmark-list-1
    * sync: all
      wipe-server: true
phase2:
  profile: profile2
  actions:
    * sync: all
    * verify:
        bookmarks: bookmark-list-1