-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathuserstories.txt
147 lines (119 loc) · 4.81 KB
/
userstories.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
-----------------------------
User Story: XXX
Title:
Description:
Acceptance Test:
----------------------------
User Story: 001
Title: Capture/replay funcionality
Description:
EastAccept should generate test scripts when a client is using the System
under Test (SUT). EasyAccept should capture clients actions and record
those actions in a "easyaccept script format". The generated script should used to
repeat the same test.
Acceptance Test:
-----------------------------
User Story: 003
Title: Choose log format
Description:
fornecer um meios de escolher a formatacao de mensagens (como log4J)
Acceptance Test:
-----------------------------
User Story: 004
Title: Exception Handling of Facade methods
Description:
When Easyaccept calls a method from a Facade and this method throws an unexpected exception,
EasyAccept does not report were the exception had ocurred.
ex:
Command: <rollDice firstDieResult="1"(java.lang.Byte)
secondDieResult="1"(java.lang.Byte)>, produced error: <This place
can't be sold>
EasyAccept should show the line of code where this excetion had ocurred
(and ,possibly, he line of scritp test that generates this error).
Acceptance Test:
-----------------------------
User Story: 006
Title: A method should receive a collections of strings as argument in scripts.
Description:
In EasyAccept scripts we should pass collections of strings as parameters.
According (for example) to the following syntax: command param={ abc, "def, ghi", "{"}
Acceptance Test:
-----------------------------
User Story: 007
Title: A method should return a collections of strings as argument in scripts.
Description:
In the current implementation, a command can only return a simple string.
A command should retur a collection of strings, the expected string
should have the syntax param={ s1, "s2, ", "{"}
Where s1 is the string representing the first object in the collection, etc.
Since EasyAccept expected results with actual results, the collections (a clss that implements Java Collection interface) returned by
Facade methods should be converted to this same syntax (or vice-versa), to allow the
comparison between "expected results" and "returned results".
For example:
expect {"John Doe","Mary Stuart"} getUserNames age=20
In this case, the getUserNames command returns a collection.
Acceptance Test:
-----------------------------
User Story: 008
Title: Improve Javadoc Comments
Description:
Enrich javadoc comments in EasyAccept code.
Acceptance Test:
-----------------------------
User Story: 009
Title: --> I DID NOT UNDERSTAND THIS USER STORY :-(
Description:
TODO treatment of collection can be better by extracting an attribute from
each object in a returned collection
example:
expect {"John Doe","Mary Stuart"} whenExtractingAttribute attribute=name getStudents class="abc"
another possible syntax
expect {"John Doe","Mary Stuart"} getStudents.name class="abc"
Acceptance Test:
-----------------------------
User Story: 010
Title: Creat a print command
Description:
The print command should simply execute a command and prints the returned result.
Acceptance Test:
-----------------------------
User Story: 011
Title: make test management easier
Description:
Test definition, packaging, execution, traceability, creation, etc. should more user friendly.
(this user story must be expanded)
Acceptance Test:
----------------------------
User Story: 012
Title: using beans
Description:
make using beans easy in easyaccept (as parameters, return values, script variables, etc.)
In other words, there are advantages to having a façade deal with beans and not only native data
since many modelues such as JSP, etc. can interface to a facade easier by dealing with beans
This should be available as return values, parameters, script variables, ...
Possible syntax
expect "John Doe" getStudent.name id=${id1}
student=getStudent id=${id1}
expect "John Doe" ${student}.name
Acceptance Test:
----------------------------
User Story: 013
Title: pdf file comparison
Description: have a built-in command to compare pdf files but skipping fields inside the pdf
that correspond to dates, serial numbers, etc.
Possible syntax:
equalFiles type=pdf file1=xxx file2=yyy
The command equalFiles file1=xxx file2=yyy would be equivalent to
equalFiles type=binary file1=xxx file2=yyy
Another possibility would be to compare files considering \r\n and \n to be the same:
equalFiles type=text file1=xxx file2=yyy
Acceptance Test:
----------------------------
User Story: 014
Title: createObject command
Description:
Implement the createObject command, which instantiates an object from a class in the code being tested.
This command should be used with discretion if the client is a non-technical person, or tests might become too confusing for him.
Possible syntax
customer1=createobject class=project.Customer name="John Doe"
customerPays customer=${customer1} value=1000