[news.eclipse.tools.hyades] Re: test creating architecture

[mgn@xxxxxxxxxxxxx (Mike Norman)]

Hi Jan,

I think we're thinking along incredibly similar lines. The Hyades
prototype model is due to be published on these newsgroups very soon (a
week or so). There has been a lot of discussion about dealing with data
more or less in the way that you are talking about. There is a proposal to
have a function known as a picker which maps between the data "pool" and
the input/output parameters of the sequence of function calls against the
SUT. This data "pool" is a relatively abstract concept (rather than the
set of two-dimensional spreadsheets commonly favoured by testing vendors),
and you can think of the picker as a generator function for valid
input/output parameters to be passed to function calls. 

I'm deliberately avoiding UML terminology in describing this, but the
whole thing is described in UML and persisted in EMF inside the Eclipse
Workbench. This means we're working through the UML type structures rather
than XSL.  These may align in due course.

Hope this makes sense.  I'm absolutely convinced we are talking about the
same thing.

Hang in for a couple of weeks and some stuff on this will appear on these
newsgroups.

Mike Norman,
Hyades Project Lead
 
 
Jan Topinski wrote:

> Hi,
> I'm working in an internal project (in polish consulting firm Infovide) 
> providing us whith testing framework. The project is run by QA team 
> (part time). The project is in a very early stage. Week ago we 
> discovered Hyades :), we liked it and decided to follow you - now we 
> must decide what it means. For easer reading let us call our project 
> Platforma(framework in polish).
> I compared our architecture with Hyades. Platforma is of course much 
> simpler but in general compatible. There is one point in which they seem 
> a little bit diffirent - test creation (and execution in some way). 
> Hyades  treats test creation as a whole. Creating (recording, 
> generation) of interface model (I like the idea from thread "Autoated 
> GUI testing") and   creating test model. And in case of Platforma we 
> have interface model, test model(test scenario) and data model (nothing 
> new yet). We planed to manage data in standarized form (DOM objects) so 
> we can provide standard data compariton/syntax testing/generation 
> functions, reuse data generators, and easer reuse of whole tests in 
> diffirent AUT.
> But the key diffirence is data generation module (we have limited 
> functionality but working version). First you give the definition of 
> "properly built object" (xml schema with extentions), so generator can 
> randomly generate objects accepted(warning simplification!) by AUT. Then 
>   you can define modifications to schema, so your objects fit specific 
> business scenario needs or are not "properly built object" so you can 
> test if AUT reject such object. This two (definition and modification) 
> are separated to keep one current version of object definiton. When test 
> is executed test engine can also make modification request to the 
> generator (eg. to randomly regenerate part of object upon AUT answer).
> Generation module is now in use in a project in which tests are disigned 
> using methodology of data driven tests. Data driven tests are useful for 
> eg. when testing batch processing, there is no (or very simple) test 
> script totaly data dependent, all test logic is kept in data objects. 
> Objects are randomly generated.
> Hope this ideas will be useful. If you have some more answers on 
> what/when questions it would be easer for us to decide how to "cope" 
> with Hyades in our project (we will redesign it for sure).
> Best regards,

>                      Jan Topinski
>                      (consultant)
>                  Infovide S.A. www.infovide.pl