[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes and more
All:
1. We have Mike Kass nominating for IIC secretary.
Please vote: send YES / NO / ABS vote by email by Wednesday May 19, 6pm PT.
2. Minutes attached.
A few action items: use case material (Monica / BPSS)
we need to keep solving existing use cases in the simplest way.
3. Next meeting Monday May 24th (no meeting next week)
Host: Fujitsu
Time: 2pm PT, Monday May 24
Toll only : 1-512-225-3050
Participant code: 716071
--------------------- Agenda
1- secretarial position: results on vote for Michael Kass.
2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting, based on use cases.
- timeout control: primitives, design patterns.
- conditional branching: redesign (which place in the scrip language?).
- loops: (iterating several test steps, is that a particular branching?)
- covering BPSS test requirements.
3- TestFramework 1.1 : test configurations for BSI (BPSS engine)
- role of existing Test Service.
- role(s) of Test Driver, simulating busienss activities.
4- Schedule for releasing TestFramework 1.1
Regards,
jacques
<<IIC_May_10_04_minutes.txt>>
Time: Monday May 10, 2004, 2pm PT (joint with New Orleans f-2-f, Thu Apr 29) Host: Fujitsu Toll only : 1-512-225-3050 Participant code: 716071 Attendees: Michael Kass (NIST) Monica Martin (Sun) Jacques Durand (Fujitsu) Pete Wenzel (SeeBeyond) excused: Steve Yung (Sun) Agenda: 1- secretarial position: only Michael Kass nominated, so we will vote if we have quorum, else we open a mail vote (1 week). 2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting. - go through use cases (see attached) and decide which operators in TFk1.1 are sufficient to best script them. - recap of BPSS choreography patterns and what operators are most familiar to workflow. - outline what simplifications can we do to TFk1.1 scripting, while covering BPSS test requirements. 3- TestFramework 1.1 : what Test Service for BSI (BPSS engine)? - at f-2-f, we have outlined the possibility of using a subset of Test Driver, to simulate the application components that process and send payloads via the BSI. -------------------------- minutes --------------------------------- 1. Secretary - Mike only nominee. Will open the vote by email. 2- TestFramework 1.1 Follow-up on the simplification of control flow operators for test case scripting 2.a: time control - we reviewed the use cases. Use case #1: timing operators today cannot handle "TimeToPerform" (BPSS) - we need more powerful primitives (not necessarily higher level) - Pete> need also to control timing of "retries", e.g. reliability. That is, duration of an iteration. (need use case #4) - Mike> XPath 3.0 support time conditions. - Test log couldbe queried - but not everything goes to the log. - issue: we need to be able to time any arbitrary sequence of steps. SOme of these sequences may also overlap. Cannot just associate timeouts with threads. - Monica> need to time bus transactions, and the entire bus collaboration that include these (nesting), and we don't want to "wait" until a timeout to fail/pass the test case. - outline of a solution: need a primitive to log a date/time value (with identifier), and then at any point in the test case, a testAssertion can compare this to current time (we can always specify a primitive that gives current date/time), and make fail/continue decision. An exception thread could be started just to loop on this check and fail the test case if timeout expired. - Accommodating BPSS opeators and concepts? (i.e. having these built-in the framework?) Monica and Jacques believe we don't have to: we don't want the test driver to become a BPSS engine (and just that). But if the test case script language uses more general and low-level primitives that can test any BPSS bus transaction or collaboration, then it should be possible to generate such a test case script (concrete syntax) from a BPSS definition. 2.b: Conditional statements: - Monica will provide input on conditional branching for bus collaborations. - The concept of "if <thread> then ..." is unnatural to Workflow users. It seems what we need is "if <assertion> then..." where <assertion> if XPath based, on same nature as regular test assertion elements. - Does not have to be part of (nested in) existing test steps ops either: could be an extenal branching op like split. 2:c: loops: - not good support for this yet: need looping over several test steps. - Monica will get Dale Moberg white paper on this. 3- TestFramework 1.1 : what Test Service for BSI (BPSS engine)? - Testing BSI can be considered at two levels: (1) conformance testing where a BSI is tested from the "other party" side. Test Driver then simulates one side of the process "on the wire" (2) interop testing where two BSIs are communicating according to a BPSS def. Test driver then has to simulate one of the applications (i.e. implements "business activities" that consume and generate messages.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]