
|
If you were logged in you would be able to see more operations.
|
|
|
WET
Created: 16/Sep/06 04:27 AM
Updated: 09/Jul/07 02:00 AM
|
|
| Component/s: |
Test controller
|
| Affects Version/s: |
0.8.0,
0.9.8_beta1,
0.9.8 Final
|
| Fix Version/s: |
1.0.0
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
The current mechanism of using precondtions and teardowns is highly confusing. This is a big detterent for using preconditions and teardowns. Although the preconditions and teardowns are very powerful ways of managing tests, they are being used less thanks to the above limitations. Make the preconditions / teardowns (test libraries in general) more simple to use.
The following is the inital plan. Please add more of your ideas to this issue:
1) Library tests are nothing different from an ordinary test
2) Library tests may have one or more transactions - (although the suggestion would be not to use too many transactions)
3) When a library test is invoked using call script, an additional (optional) parameter is added:
current definition:
def call_test(filename, args)
proposed definition:
def call_test(filename, args, trans_to_use=nil)
The trans_to_use decides as to which transaction needs to be run. If nil is passed, then the operation switches to the current mode - that is, use the root transaction. This is also true if trans_to_use is not passed at all.
In the second mode, you can pass a string for the trans_to_use parameter. In this case, only the transaction whose name==passed_argument, is run in the library test.
|
|
Description
|
The current mechanism of using precondtions and teardowns is highly confusing. This is a big detterent for using preconditions and teardowns. Although the preconditions and teardowns are very powerful ways of managing tests, they are being used less thanks to the above limitations. Make the preconditions / teardowns (test libraries in general) more simple to use.
The following is the inital plan. Please add more of your ideas to this issue:
1) Library tests are nothing different from an ordinary test
2) Library tests may have one or more transactions - (although the suggestion would be not to use too many transactions)
3) When a library test is invoked using call script, an additional (optional) parameter is added:
current definition:
def call_test(filename, args)
proposed definition:
def call_test(filename, args, trans_to_use=nil)
The trans_to_use decides as to which transaction needs to be run. If nil is passed, then the operation switches to the current mode - that is, use the root transaction. This is also true if trans_to_use is not passed at all.
In the second mode, you can pass a string for the trans_to_use parameter. In this case, only the transaction whose name==passed_argument, is run in the library test. |
Show » |
|
http://svn.openqa.org/fisheye/changelog/wet?cs=635