test-factory 0.1.9 → 0.1.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/README.md CHANGED
@@ -172,63 +172,63 @@ Design Pattern
172
172
  The TestFactory was written assuming the following guiding principles. Any code that does not
173
173
  follow them probably [smells](http://en.wikipedia.org/wiki/Code_smell), and should be refactored.
174
174
 
175
- 1. Page Classes contain methods relating to interactions with page elements only--meaning
176
- the getting or setting of values, or the clicking of links or buttons. Any more
177
- complicated page interactions are handled in the Data Object classes, or in the test
178
- step definitions.
179
- 2. Data Objects represent definable data structure entities in the system being tested.
180
- As data, they fit into the [CRUD Model](http://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
181
- and thus have methods that correspond to those basic functions.
182
- 3. Data Objects have a single method for each of the CRUD functions, and additional
183
- custom methods are avoided without compelling arguments for their inclusion in the class.
184
- 4. When a Data Object is executing its `edit` method, first the data in the
185
- system under test is updated, then the data object's instance variables
186
- are updated--using DataFactory's `set_options`.
187
- 5. Site navigation is handled using conditional methods (meaning they only navigate if
188
- necessary) inside the Data Object--and preferably inside the data object's CRUD methods
189
- themselves--unless there are specific reasons to explicitly navigate in a step
190
- definition. This keeps step definitions from being unnecessarily cluttered.
191
- 6. Specifying non-default test variables for data objects is done using key/value hash
192
- pairs that are parameters of the data object's CRUD methods. It is _not_
193
- done by explicitly assigning values to the instance variables. Examples:
194
- ```ruby
195
- # During object creation, following the name of the class
196
- @data_object = make DataObject, :attrib1 => "Custom Value 1", :attrib2 => "Custom Value 2" # etc...
197
-
198
- # When an object is edited (using Ruby v1.9.3's Hash syntax is optional)
199
- @data_object.edit attrib1: "Updated Value 1", attrib2: "Updated Value 2"
200
-
201
- # This is frowned upon because it can easily lead to
202
- # the data object and the data in the test site being
203
- # out of sync, leading to a false negative test result:
204
- @data_object.attrib1="Another Value"
205
-
206
- ```
207
- 7. Updates to a data object's instance variables is handled *only* by the `set_options` method, *not* explicitly.
208
- ```ruby
209
- # This is good
210
- def edit opts={}
211
- #...
212
- page.element.fit opts[:value]
213
- #...
214
- update_options(opts)
215
- end
175
+ * Page Classes contain methods relating to interactions with page elements only--meaning
176
+ the getting or setting of values, or the clicking of links or buttons. Any more
177
+ complicated page interactions are handled in the Data Object classes, or in the test
178
+ step definitions.
179
+ * Data Objects represent definable data structure entities in the system being tested.
180
+ As data, they fit into the [CRUD Model](http://en.wikipedia.org/wiki/Create,_read,_update_and_delete)
181
+ and thus have methods that correspond to those basic functions.
182
+ * Data Objects have a single method for each of the CRUD functions, and additional
183
+ custom methods are avoided, unless there are _compelling_ arguments for their inclusion in the class.
184
+ * When a Data Object is executing its `edit` method, first the data in the
185
+ system under test is updated, then the data object's instance variables
186
+ are updated--using DataFactory's `set_options`.
187
+ * Site navigation is handled using conditional methods (meaning they only navigate if
188
+ necessary) inside the Data Object--and preferably inside the data object's CRUD methods
189
+ themselves--unless there are specific reasons to explicitly navigate in a step
190
+ definition. This keeps step definitions from being unnecessarily cluttered.
191
+ * Specifying non-default test variables for data objects is done using key/value hash
192
+ pairs that are parameters of the data object's CRUD methods. It is _not_
193
+ done by explicitly assigning values to the instance variables. Examples:
194
+ ```ruby
195
+ # During object creation, following the name of the class
196
+ @data_object = make DataObject, :attrib1 => "Custom Value 1", :attrib2 => "Custom Value 2" # etc...
216
197
 
217
- # This is not good
218
- def edit opts={}
219
- #...
220
- page.element.fit opts[:value]
221
- #...
222
- @value=opts[:value] unless @value==opts[:value]
223
- end
224
- ```
225
- 8. The setting of random values for select lists in a data object is determined by passing
226
- the symbol `:random` in the instance variable or as the value in the key/value pair
227
- passed in an `#edit` method's `opts` parameter. The `#create` and `#edit` methods will
228
- handle the necessary logic. The purpose is to prevent the need for custom randomizing
229
- CRUD methods in the data object.
230
- 9. See the gem_ext.rb file's discussion of the Watir `#fit` method for additional
231
- design pattern rules to follow.
198
+ # When an object is edited (using Ruby v1.9.3's Hash syntax is optional)
199
+ @data_object.edit attrib1: "Updated Value 1", attrib2: "Updated Value 2"
200
+
201
+ # This is frowned upon because it can easily lead to
202
+ # the data object and the data in the test site being
203
+ # out of sync, leading to a false negative test result:
204
+ @data_object.attrib1="Another Value"
205
+
206
+ ```
207
+ * Updates to a data object's instance variables is handled *only* by the `set_options` method, *not* explicitly.
208
+ ```ruby
209
+ # This is good
210
+ def edit opts={}
211
+ #...
212
+ page.element.fit opts[:value]
213
+ #...
214
+ update_options(opts)
215
+ end
216
+
217
+ # This is not good
218
+ def edit opts={}
219
+ #...
220
+ page.element.fit opts[:value]
221
+ #...
222
+ @value=opts[:value] unless @value==opts[:value]
223
+ end
224
+ ```
225
+ * The setting of random values for select lists in a data object is determined by passing
226
+ the symbol `:random` in the instance variable, or as the value in the key/value pair
227
+ passed in an `#edit` method's `opts` parameter. The `#create` and `#edit` methods will
228
+ handle the necessary logic. The purpose is to prevent the need for custom randomizing
229
+ CRUD methods in the data object.
230
+ * See the gem_ext.rb file's discussion of the Watir `#fit` method for additional
231
+ design pattern rules to follow.
232
232
 
233
233
  Notice
234
234
  ------
@@ -14,9 +14,17 @@
14
14
  # Proper use of the +#fit+ method requires following a particular coding
15
15
  # pattern, however:
16
16
  #
17
- # 1. In your Page Classes, define your text fields, select lists, radio buttons, and checkboxes directly. Do not define +#select+, +#set+ and/or +#clear+ actions there.
18
- # 2. Your data object's instance variables for radio buttons and checkboxes, when not +nil+, should have the values of +:set+ or +:clear+. If they *need* to be something else, then define a Hash transform method to easily convert the custom values back to +:set+ or +:clear+, then pass that transform to the +#fit+ method.
19
- # 3. Always remember to end your +#edit+ methods with the +#set_options()+ method (a.k.a. +#update_options+), from the DataFactory module. It automatically takes care of updating your data object's instance variables with any new values.
17
+ # * In your Page Classes, define your text field, select list, radio button, and
18
+ # checkbox elements directly. Do not define +#select+, +#set+ and/or +#clear+
19
+ # actions there.
20
+ # * Your data object's instance variables for radio buttons and checkboxes, when
21
+ # not +nil+, should have the values of +:set+ or +:clear+. If they *need* to be
22
+ # something else, then define a Hash transform method to easily convert the
23
+ # custom values back to +:set+ or +:clear+, then pass that transform to the +#fit+ method.
24
+ # * Always remember to end your +#edit+ methods with the +#set_options()+
25
+ # method (a.k.a. +#update_options+), from the DataFactory module. It
26
+ # automatically takes care of updating your data object's instance variables
27
+ # with any new values.
20
28
  #
21
29
  # ==Example
22
30
  #
Binary file
data/test-factory.gemspec CHANGED
@@ -1,6 +1,6 @@
1
1
  spec = Gem::Specification.new do |s|
2
2
  s.name = 'test-factory'
3
- s.version = '0.1.9'
3
+ s.version = '0.1.10'
4
4
  s.summary = %q{rSmart's framework for creating automated testing scripts}
5
5
  s.description = %q{This gem provides a set of modules and methods to help quickly and DRYly create a test automation framework using Ruby and Watir (or watir-webdriver).}
6
6
  s.files = Dir.glob("**/**/**")
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: test-factory
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.1.9
4
+ version: 0.1.10
5
5
  prerelease:
6
6
  platform: ruby
7
7
  authors:
@@ -48,6 +48,7 @@ files:
48
48
  - lib/test-factory.rb
49
49
  - README.md
50
50
  - test-factory-0.1.8.gem
51
+ - test-factory-0.1.9.gem
51
52
  - test-factory.gemspec
52
53
  homepage: https://github.com/rSmart
53
54
  licenses: []